Adds workspace generation as part of init.

[pyjarrett]

I've found generating Visual Studio Code workspaces for projects for use with the Language Support for Ada plugin very helpful. I wasn't sure if you wanted this hidden behind an option, or if this was even a good idea in the general case.

When I've done this, I do: alr config --global --set editor.cmd "code.cmd workspace.code-workspace" to be able to easily swap between projects.

[Fabien-Chouteau]

I like having VSCode support, the only downside would the be extra file that is not going to be useful for everyone.

[Fabien-Chouteau]

We have a test that check the content of directories after init, it needs to be adjusted:

INFO     FAIL            workflows__init-options: non-zero status code
Running: /opt/hostedtoolcache/Python/3.10.1/x64/bin/python3 test.py (cwd=/tmp/tmp8jlyspok/workflows__init-options)
Status code: 1
Output: 
Traceback (most recent call last):
  File "/tmp/tmp8jlyspok/workflows__init-options/test.py", line 20, in <module>
    compare(contents('xxx'), ['xxx/.gitignore',
  File "/home/runner/work/alire/alire/testsuite/drivers/helpers.py", line 49, in compare
    assert found == wanted, 'Got:    {}\nWanted: {}'.format(found, wanted)
AssertionError: Got:    ['xxx/.gitignore', 'xxx/alire.toml', 'xxx/src', 'xxx/src/xxx.adb', 'xxx/workspace.code-workspace', 'xxx/xxx.gpr']
Wanted: ['xxx/.gitignore', 'xxx/alire.toml', 'xxx/src', 'xxx/src/xxx.adb', 'xxx/xxx.gpr']

[pyjarrett]

First try :P /s

[mosteo]

@Fabien-Chouteau I guess there's nothing blocking this one?

[Fabien-Chouteau]

I am not a huge fan of having this extra file just for VScode.
But I wont block the PR.

[mosteo]

Perhaps we can add a config option to disable it?

[Fabien-Chouteau]

Up to you and @pyjarrett. The risk with an option is that some people won't see it.

[pyjarrett]

My intent was to move towards first-class support of VS code since it's an incredibly common editor on all platforms, and would minimize friction of people to try Ada + Alire very easily. Anecdotally, nearly everyone I know has an VS Code install.

The continuation of this PR would be a setting up .vscode/ along with launch.json and tasks.json from the Ada Language Server's getting started page. For people trying out a language and tooling, basic IDE and build/run/debug support should work right out of the box. Asking people to install a separate editor for a good experience is a big ask, especially since GNAT studio isn't available through Alire yet.

Maybe a configuration option on first Alire run would set the preferred editor between GNAT studio and VS code and set this?

@Fabien-Chouteau , I understand why you don't want this specific file, which is why I had asked about the question on gitter about alr install, since my other idea had been to make this a post-setup tool you could run easily.

[pyjarrett]

@reznikmm might want to be involved in this discussion as well.

[Fabien-Chouteau]

My intent was to move towards first-class support of VS code since it's an incredibly common editor on all platforms, and would minimize friction of people to try Ada + Alire very easily. Anecdotally, nearly everyone I know has an VS Code install.

I fully agree that we have to up our VS Code game 👍

The continuation of this PR would be a setting up .vscode/ along with launch.json and tasks.json from the Ada Language Server's getting started page.

This is typically the kind of stuff I am afraid of. Extra files that will need to be maintained as the Ada plugin or VScode evolve.

For people trying out a language and tooling, basic IDE and build/run/debug support should work right out of the box. Asking people to install a separate editor for a good experience is a big ask,

100% 👍

especially since GNAT studio isn't available through Alire yet.

That may change in the near future ;)

Maybe a configuration option on first Alire run would set the preferred editor between GNAT studio and VS code and set this?

@Fabien-Chouteau , I understand why you don't want this specific file, which is why I had asked about the question on gitter about alr install, since my other idea had been to make this a post-setup tool you could run easily.

What about this: a new alr vscode command that generates the required dirs and files and then start VScode?
The dirs and files would be added to the alr init .gitignore so that people know not to check them in.
The generation of files from Alire would evolve as the plug-in/VScode evolves.

We could also rename alr edit into alr gnatstudio with the option to download and install GS if not available already.
alr edit is not so useful now that we have alr exec.

[onox]

What about this: a new alr vscode command that generates the required dirs and files and then start VScode? The dirs and files would be added to the alr init .gitignore so that people know not to check them in. The generation of files from Alire would evolve as the plug-in/VScode evolves.

We could also rename alr edit into alr gnatstudio with the option to download and install GS if not available already. alr edit is not so useful now that we have alr exec.

I think Alire should not get special commands for specific editors (that would pollute the commands list), but rather have a generic command that uses 1) a subcommand or --option=<name>, or 2) autodetects installed editors like GPS, vscode, nvim, emacs (using the presence of certain files in the user's home folder), or 3) use some configuration option.

About Generate_VSCode_Workspace... does Alire have more code that prints JSON? Another option may be to put the JSON in some .json file use the template stuff from GNATCOLL to generate the final JSON file.

Just my 2 cents.

[Fabien-Chouteau]

I think Alire should not get special commands for specific editors (that would pollute the commands list),

"Polution" of the command list doesn't seem like a strong argument to me. There are not many commands in Alire and we already have a system of categories to provide a clear list.

Now, if this is a shared concern, we can also go with:

• alr edit --vscode
• alr edit --gnatstudio

Or in the future add support for alr-something external commands like git has:
alr something --plop = alr exec -- alr-something --plop

but rather have a generic command that uses 1) a subcommand or --option=<name>, or 2) autodetects installed editors like GPS, vscode, nvim, emacs (using the presence of certain files in the user's home folder), or 3) use some configuration option.

You can already do 1) with alr exec and if you add an alias it would be even more seamless. 2) we are unlikely to use the editor that users want in practice. I have all the editors that you mention installed but I only use GS for coding in Ada.
3) That's how the current alr edit works.

The difference here is that, unlike GNAT Studio, VS code requires special files to work.

About Generate_VSCode_Workspace... does Alire have more code that prints JSON? Another option may be to put the JSON in some .json file use the template stuff from GNATCOLL to generate the final JSON file.

Templated alr init or even template crates is an interesting feature. But for 10 lines of code I think the current implementation is ok.

[Fabien-Chouteau]

@reznikmm why not define Alire tasks in the AdaCore vscode plugin?https://code.visualstudio.com/api/extension-guides/task-provider

[reznikmm]

What these tasks should do exactly?