Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: VSCode plugin to set up Alire environment correctly #1160

Open
TamaMcGlinn opened this issue Aug 26, 2022 · 1 comment
Open

Comments

@TamaMcGlinn
Copy link

Currently, the recommended workflow starts with alr edit which sets the environment necessary for working with Alire and then launches VSCode. The Ada plugin for VSCode then launches the ada_language_server and allows VSCode to communicate with it via LSP, and since the terminal launched VSCode which launches ada-language-server, the environment is carried over to each child process. This works, but...

It is really annoying to have to restart the whole editor when the alire configuration changes, or I want to switch to a different gpr project file. In my case, since I was using NeoVim, I wrote this plugin that detects that I am editing in an alire workspace and sets the environment by parsing the output of alr printenv. It also allows me to switch gpr files. If we had a similar plugin for VSCode, users could just install both the Ada and Alire plugins and everything would work automagically.

It would also enable Gitpod to work for Alire projects out-of-the-box. It is not (yet?) possible to set editor-wide environment variables, so in the meantime you need to set your gitpod dotfiles in preferences to https://github.com/TamaMcGlinn/gitpod_alire_dotfiles or include the same hackaround in your existing dotfiles. (you can try it out on Adabots_Examples by clicking here). A separate plugin would fix that because you could specify it in your .gitpod.yml for the repo.

I might write the plugin myself, but I wanted to post here to see if anyone is already working on it.

@mosteo
Copy link
Member

mosteo commented Aug 26, 2022

I'm not, and it looks like a valuable QoL improvement. I think @reznikmm is quite experienced with VSCode, so I'm pinging him just in case he has some input to offer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants