Autoupdate language server version

[gnikit]

Because fortls is used by multiple editors, it is the client's responsibility to have the latest version of fortls, however this creates a problem on our end. Users end up with outdated versions due to the client implementation not having a way to notify the user.

I think during initialisation we should check PyPi and if our version is older than that in the repo we should download the latest.

This should also minimise the maintenance of multiple versions since users will always be running the latest fortls version.

A flag should be added to disable this auto update in case new versions introduce breaking changes, but I would highly recommend against enabling that option.

[bilderbuchi]

Personally, auto-updating/installing packages behind the scenes feels way way too surprising for my taste, e.g. (as a conda user) if the update suddenly pulls in more dependencies via pip that are available via conda and should be installed via conda.
Especially by default, which afaict as a user of fortls via the FORTRAN IntelliSense VS Code extension I cannot even disable with the introduced flag.

A notification/warning is fine, but where and when and how a package is updated should be the sole responsibility of the user.

[gnikit]

auto-updating/installing packages behind the scenes feels way way too surprising for my taste,

I understand but you have to also consider, how difficult and time consuming it is for us (me, since there is no one else developing fortls) to develop and support old versions. Especially since this is not a monetised project.

via the FORTRAN IntelliSense VS Code extension I cannot even disable with the introduced flag.

In VS Code you should not be using FORTRAN Intellisense anymore. It is redundant, the Modern Fortran extension should be enough. Moreover, one of the features of fortls is that all command-line arguments are also available to set via a configuration file i.e. --disable_autoupdate can be set in .fortls (or however you have called you configuration file) by doing "disable_autoupdate": false,

A notification/warning is fine, but where and when and how a package is updated should be the sole responsibility of the user.

Although that is an option most language servers employ a similar autoupdate technique. It shouldn't matter to the user what version your language server is. There are a lot of arguments to be made on this. I am more than willing to have a discussion on the matter, see how the users feel and if so revert the auto-update feature.

[bilderbuchi]

In VS Code you should not be using FORTRAN Intellisense anymore. It is redundant, the Modern Fortran extension should be enough.

Ah, thanks, I was not aware that that extension was made redundant, at some point in the past I installed both -- Thanks!

Moreover, one of the features of fortls is that all command-line arguments are also available to set via a configuration file i.e. --disable_autoupdate can be set in .fortls (or however you have called you configuration file) by doing "disable_autoupdate": false,

Ah, good to know. From the documentation I infer that this file has to reside in every project I use fortls on, as it does not search e.g. upwards in the directory hierarchy, or in the home directory if no config file is found in the root dir. Is that correct?

Also fwiw, "Options defined in the configuration file have precedence over command line arguments." is, in my experience, basically the opposite behaviour of most tooling (linters, etc) I'm using, where the precedence is defaults < config file entry < command line switch. Otherwise, it's impossible to temporarily override undesired behaviour without code changes.

[bilderbuchi]

I understand but you have to also consider, how difficult and time consuming it is for us (me, since there is no one else developing fortls) to develop and support old versions. Especially since this is not a monetised project.

I fully understand, being in a similar boat; only supporting the latest version is quite natural.

However, consider that auto-updating with pip means that for users having installed fortls via conda, this will replace the conda version with a version from pypi, and crucially, will also install any new dependencies via pip instead of conda.

This means that the environment (maybe even the base env) slowly becomes a mix of pypi and conda packages, a situation you want to avoid as much as possible, and would normally mitigate by installing as many dependencies as possible via conda before doing a (manual) pip install.
I wanted to demonstrate that with 2.2.7 that introduces the packaging dependency, but that's not yet visible on pypi.

[bilderbuchi]

Lacking a notification method that the users would see (because it's hidden in some editor log, I guess?), fortls could error out with a descriptive error message when it hits that "have to update" codepath - that would normally be surfaced by editors, I think.

[gnikit]

Also fwiw, "Options defined in the configuration file have precedence over command line arguments." is, in my experience, basically the opposite behaviour...

I agree but there is a reason for that. fortls is launched from the command line in most Editor extensions. Moreover the development cycle of each editor extension varies and certainly does not match, the dev cycle of fortls. So whenever I make a change (possibly breaking), I would have to get every editor's extensions updated. That is not possible. The obvious solution is to allow for project settings i.e. json files, to override command line args, since command line args are effectively "global args".

However, consider that auto-updating with pip means that for users having installed fortls via conda, this will replace the conda version with a version from pypi, and crucially, will also install any new dependencies via pip instead of conda.

tbh I don't see a problem with that, but I also don't want to change people's conda envs. What I think I can do is detect if we are in a conda environment and if so just show a notification.

Lacking a notification method that the users would see (because it's hidden in some editor log, I guess?), fortls could error out with a descriptive error message when it hits that "have to update" codepath - that would normally be surfaced by editors, I think.

I think we can do that. We can generate a pop-up message and even display options for the user to select. The only problem is getting the response from these options.

[bilderbuchi]

I agree but there is a reason for that.

Understood. It's great that this is specifically called out in the docs!

What I think I can do is detect if we are in a conda environment and if so just show a notification.

Sounds good!

I think we can do that. We can generate a pop-up message and even display options for the user to select. The only problem is getting the response from these options.

Do you necessarily need to "get" a response? If you error out with "fortls is outdated, please update it!" and the user updates fortls (using pip, conda, apt-get, msys-pacman, or whatever they are using), would that be sufficient (as the error would not re-appear)?