Create codespace config

[spenserblack]

I was thinking of using a codespace to make a PR, but then I discovered I couldn't! 😱

This adds configuration to allow a user to create a codespace that includes the necessary prerequisites to compile (Rust toolchain, cmake). It also adds a couple of helpful VS Code extensions for VS Code on the Web:

• EditorConfig, because it should be an extension if this project uses it
• Rust Analyzer, to provide helpful support like type analysis

This PR also generalizes the EditorConfig from a specific package.json to all *.json files. Before I create any file I see if it matches an EditorConfig entry and, if not, I modify it so it's included. This change was a best guess of preferred behavior.

[Byron]

That's a great addition, thank you!
Please feel free to keep modifying it as you see fit, improvements will always be appreciated.

I don't know if there is a way to select multiple dev containers, for instance, one could also have a VIM plugin pre-installed.
On the other hand, maybe there is a way to get per-user customisations in another way.

[EliahKagan]

I don't know if there is a way to select multiple dev containers, for instance, one could also have a VIM plugin pre-installed.

If you mean the Vim extension for VS Code (vscodevim), depending on how you have things set up to sync, I think that may install automatically in subsequent codespaces once you've installed it before.

If it doesn't, then clicking on the extension and clicking the gear icon (to the right of Disable, Uninstalled, and Auto Update, and tooltipped "Manage") and checking Sync This Extension may help. That box is checked for several extensions that install automatically for me in codespaces regardless of whether they are requested by the dev container configuration.

However, I don't think this will be preinstalled in the dev container, because I don't think VS Code extensions ever are. A dev container configuration can specify extensions (and this one does), but those are automatically installed immediately after the dev container is created, rather than being present at the time it is created.

In contrast, if you mean the vim command itself, then that could be installed along with cmake (or like this, though as long as cmake is installed with apt, any other such needed software may as well be installed along with it). This would entail modifying the dev container configuration. But if this is something you find useful to run in a dev container then I think it would be reasonable to do so. As it stands, the vim-tiny package is installed, which provides a "compact version" (as the Debian package description says it) of Vim as vi.

So I don't know if multiple dev container configurations are really needed for this. But they can be created. This is done by placing separate devcontainer.json files in subdirectories of .devcontainer, as detailed here in the specification and commented on here. I am not sure if all clients support selecting them, though, and in particular, I am not sure if or how well this works for codespaces. (In addition to running in codespaces, dev containers can also be run locally if you have Docker.)

[Byron]

Thanks for taking a look. I have a feeling that at least one part of my question would have been answered if I just ran it once, which I never did 😅.

In contrast, if you mean the vim command itself, then that could be installed along with cmake (or like this, though as long as cmake is installed with apt, any other such needed software may as well be installed along with it). This would entail modifying the dev container configuration. But if this is something you find useful to run in a dev container then I think it would be reasonable to do so. As it stands, the vim-tiny package is installed, which provides a "compact version" (as the Debian package description says it) of Vim as vi.

Indeed, I was thinking about the VSCode extension, and it sounds like this would happen automatically. When (or if) I start using codespaces, I will see how it goes.

[spenserblack]

I don't know if there is a way to select multiple dev containers, for instance, one could also have a VIM plugin pre-installed.

As @EliahKagan said a user can install their own preferred extensions, and with settings sync set up those extensions will be installed automatically. But even without settings sync, GitHub seems to somehow remember the extensions a user has manually installed to install them again. Since the vim extension is more of a personal preference than one that's required/recommended, I'd say it's better to let the user manually install that extension than provide an alternate config that would install it.

But, yes, it is possible to have multiple dev containers if needed. Here is one for working on a project's website instead of the main project, for example.

[Byron]

Nice! Thanks everyone for their involvement, I learned a lot today!

[EliahKagan]

I had wrongly suggested that multiple dev container configurations may be hard to use with codespaces:

I am not sure if all clients support selecting them, though, and in particular, I am not sure if or how well this works for codespaces.

That may once have been true, which may be what gave me that impression, I'm not sure. But both the web interface and the Codespaces extension in VS Code allow this to be selected.

• In the web interface, it is in "New with options..." as documented.
• In VS Code with the Codespaces extension, when there is more than once choice of devcontainer.json file to use, the editor prompts the user to select which one (much as it prompts the user for branch and for codespace size).

There are other clients, and I would guess that they may also support selecting this, but I have not tested them.