Is Alire support in the lsp-mode Ada client still needed?

[brownts]

Hi @vaartis and @dkm, I wanted to reach out to you since you either added and/or modified Alire support in lsp-mode. I'm running into an issue and wanted to touch base before implementing a change.

Loading of the Alire environment prior to starting the Ada Language Server was added to lsp-mode in 2021. In 2023 the Ada Langauge Server was updated to perform this activity when an alire.toml file is found in the root directory (see this commit). It appears this environment loading only occurs when the project file is not supplied as part of the LSP initialize request, which for lsp-mode can be accomplished by setting lsp-ada-project-file to nil.

However, I'm running into an issue where I can't get the Ada LS to automatically find the project file via alr when I set lsp-ada-project-file to nil, to prevent lsp-mode from specifying the value in the initialize request. The reason for this was the introduction of an explicit test in the Ada LS for the ALIRE environment variable to prevent running of the alr executable, caused by issue AdaCore/ada_language_server#1129 which changed the behavior in ALS 23.0.15. This prevents the Ada LS from running "alr --non-interactive show" and extracting the "Project File" property from the output (or using the crate name when the property is not found). Since this environment variable is part of the environment generated by "alr printenv --unix" (called from lsp-ada--environment), there are a couple ways around this:

• Set lsp-ada-alire-executable to nil (or some non-existent executable) and update lsp-ada--environment to not populate the Alire environment variables under this condition.
• remove ALIRE from the generated environment (or change it's value to False) to allow the Ada LS to run alr and find the project file.
• Remove support for Alire from the lsp-mode Ada client, and since the ALIRE environment variable wouldn't be defined, the expected behavior would occur.

To me, I think the last option might be the best, especially if the lsp-mode Alire support is now duplicating functionality that resides in the Ada LS. The other options cause alr to be run twice (once via lsp-mode and once by the Ada LS).

If the environment setup for Alire were removed from lsp-mode, It would still be necessary to force the value of lsp-ada-project-file to nil to trigger the Ada LS to search for the alire.toml file. I don't think the current value of lsp-ada-project-file (i.e., "default.gpr") helps anyone. It prevents the automatic discovery of the project file by the Ada LS and since the Ada LS fallback is to eventually look for a .gpr file in the top-level project directory, it seems like this default value really should be changed to nil (so it's not specified by default in the initialize request). From my understanding, Ada LS will use the project file in the following order of precedence:

• project file specified in the initialize request
• when alire.toml exists, project file configured in it and populate environment (see README)
• when alire.toml exists, project file not configured in it, use name of crate with .gpr extension and populate environment
• Existing .gpr file in root directory (when it's the only one there)

My thought, since it appears the lsp-mode Alire support is redundant with what a newer (within the last year) Ada LS would normally provide in the absence of a specified project file, is to change the default for lsp-ada-project-file from "default.gpr" to nil and to remove the Alire environment setup in lsp-mode, as I think it would give the best out-of-the-box experience. What do you think about this change? Do you see any potential issues with this? Maybe there is something I missed in this analysis. Thanks.

[vaartis]

I trust your judgement on this. If support was added to Ada LS, there is no need to duplicate this functionality. I also used to set the .gpr file in .dir-locals manually whenever I used this, if it will now find it properly by default that would be much better.

[dkm]

Same for me... I don't use the lsp-mode with ALS nor do I regularly use Alire, so I'm not sure I'll be able to give any meaningful feedback, sorry.

[brownts]

Sorry for the delayed response, thanks for the feedback from both of you. I will go ahead and submit a PR to remove Alire support from lsp-mode.

I trust your judgement on this. If support was added to Ada LS, there is no need to duplicate this functionality. I also used to set the .gpr file in .dir-locals manually whenever I used this, if it will now find it properly by default that would be much better.

I've typically configured .dir-locals.el as well, although I've encountered trouble with this where it hasn't worked properly for quite a while (#4337) and have provided a PR (#4349) which has yet to be merged. I'm not sure why there is a delay in getting this merged. Anyway, this nuisance is one of the reasons I'd prefer to have the Ada LS just find the project file if possible. That along with not having to provide Emacs-specific configuration for a project seems ideal.

Same for me... I don't use the lsp-mode with ALS nor do I regularly use Alire, so I'm not sure I'll be able to give any meaningful feedback, sorry.

I don't use Alire much yet, but I wanted to make sure changing the default value of of lsp-ada-project-file wasn't going to affect it, and that's when I stumbled on the issue with the lsp-mode environment setup essentially disabling the Alire project file discovery functionality within the Ada LS.