I am wondering how users of Anaconda, Homebrew and any other robust and mature package management system would feel if a package in their system was performing automatic updates behind the scenes.
I thought it would be a good idea to put this question up to the community since we are predomintately the users of fortls.
Additional context
fortls emits a notification when an outdated version is detected. It will only take action and attempt and auto-update if it has been installed via the official Python package management system (pip). For Anaconda and Homebrew environments, only the notification is shown to ensure that fortls does not break the corresponding environment.
Poll time
fortls should auto-update (in conda & brew)
fortls should NOT auto-update (in conda & brew)
0voters
If you have any thoughts on why it is or isn’t a good idea to auto-update (or why it doesn’t matter) please post them below.
My opinion
Ideally, I would remove all auto-updating functionality and leave the responsibility to the users. Unfortunately, in practice and over the past 2+ years a substantial portion of reported Issues came from users with outdated versions, which is how the pip auto-update functionality came to be. After the functionality was added (along with some other measures) such reports dropped almost to zero.
~
Secondly, I consider conda and brew orders of magnitude better package management systems than pip, which is why I feel strongly against features that circumvent their version control and hinder their robustness.
~
Specifically for conda and in addition to my previous comment, such auto-update feature could break the conda-forge feedstock workflow, while for brew they outright dislike auto-updating tools.
I think it would be better to have a small message saying that “your current fortls version is out of date, please consider upgrading to the latest version” etc etc… auto-updating tools and packages are also seen with bad eyes by IT managers, so another risk that in any case those updates might be blocked by the local administrators.
The proposed change is to merely add the capability of auto-updating. It is noteworthy that the default behavior in the PR in conda environments remains to NOT update automatically, and this is a feature users would need to opt into. It does not circumvent conda versioning either; it performs a system call conda update -c conda-forge --yes --quiet fortls. Per documentation, the conda update command will update “to the latest versions that are compatible with all other packages in the environment.” (conda update — conda 23.11.1.dev39 documentation). The update would not be performed if your package spec for your environment did not allow it.
I think the poll is good for determining what the default setting should be; if by some surprise a majority felt that it SHOULD auto-update, then perhaps making it enabled by default is the right approach. I wouldn’t go as far as to say it should never auto-update.
Hence why I submitted the PR just to add the ability to update, not to force it.
I do like the idea of having the option to autoupdate. Doesn’t VSCode have a setting for this? It seems like every time I open it it is updating something.
As I mentioned in the PR just because we offer multiple ways of installing fortls and we also offer an auto-update mechanism, that does not mean that we should take the burden of maintenance of the auto-update mechanism for every distribution channel and supported management system. This increases the complexity and is simply outside of the scope of the tool of a language server. This is the job of the user or an IT admin, that’s why the notification exists.
The PyPi auto-update functionality was added to keep the inflow of already fixed issues to a minimum, and to that end it seems to have worked.
It does but for its extensions which are listed in the VS Code marketplace. The equivalent in this context would be a VS Code extension (fortls) updated itself instead of allowing VS Code (conda) to do it; this is never the case. If the packing system you use contains non-trivial dependencies this action will break it, conda and the conda-forge channel tend to be used for such things.
I don’t think its the responsibility of a package to update itself while being part of an ecosystem that permits safe updates.
I am not sure if such auto-update functionality for non-PEP utilities should live on the code editor or be part of an IT policy, but I am relatively certain that it shouldn’t be part of the server (also supported by the lack of other servers performing this action).
I understand the current poll «fortls should/should NOT auto-update» as a one-time choice. But if there is a project pursued over multiple days, the (perhaps for shorter projects reasonable) pick of an automatic update of the conda packages can be bad, an automatic update the next day possibly could affect the work with locally written source code. This is why I support your suggestion to offer a decision by case if an update is launched.
A recent example where the user has to pick any of these three update modi is DataWarrior
I don’t have any opinion about fortls specifically, but in general I have some software packages that I want to automatically update and I have others that I want to do manually. A compiler would be something that I would want to update only manually. Adobe Reader, just to give an example, is something that I might want to update automatically.
