Implement dev containers spec

[AngellusMortis]

Problem description

Implement dev containers spec https://containers.dev/implementors/spec/

VS Code/Microsoft originally created this and other tools have been adopting it. Notably JetBrains is working on implementing it as well. Dev containers allows a team within an org to manage all of the tools and setup for a development environment without each dev needing to manage their own nvm/pyenv/etc. It automates a ton of steps, especially when combined with the customizations section to automatically configure tools for linting/testing.

Preferred solution

Sublime Text should support the dev containers spec

Alternatives

Not really any alternatives.

Additional Information

No response

[Thom1729]

Would a third-party plugin be a possible alternative? Or would that be impossible for some reason?

Also, can you give an example of some of the use cases from a text editor perspective? The spec is a bit dry.

[AngellusMortis]

No, it is not really possible with a plugin because it is a pretty big architecture that has to be built in and supported. Basically, the way it would work in terms of an editor (at least how VS Code and JetBrains implements it), is the backend for the editor is split into two a server and a client. The server is then able to run on a different machine then the actual editor and the two communicate back and forth. Kind of like a LSP, but for the whole editor.

Then additionally, plugins (again based on how VS Code implements it) then also become two sided. Most of them (like LSPs/language support ones) would be installed on the server side and just communicate data back via the server/client API. But some of them could be 100% client side (like template generator ones, like Emmet). This would allow things like working on a Python project without actually having a Python interrupter installed on your system (or having to manage one for every individual project you work on).

Dev Containers is only a small part of the whole idea and feature as VS Code also has Remote Development inside of a WSL instance, over SSH or inside of a Github CodeSpace. JetBrains also has their own GitHub CodeSpaces competitor as well and there are even more plugins/extensions for both that allow things like developing inside of a remote AWS/GCP VM or other "Code as a Service" platforms like Gitpod.

I mostly only made this ticket because we as an org are going down the "fully containerized" route, even in development. I know there are at least a handful of devs that use Sublime Text. If Sublime Text does not support devcontainers, then they will be forced to either have an inferior experience or use VS Code/JetBrains.

[Thom1729]

Ah. I suspect that the Sublime devs are not going to re-architect the application to work with a new Microsoft protocol that currently seems to work well only in VSCode.

(As a developer myself, I might also recommend caution in basing your development environment around a new Microsoft protocol that currently seems to work well only in VSCode. But that's just my opinion.)

It sounds like for now, the “inferior experience” of Sublime users is that they would be forced to keep using standard tools like nvm? Or just ssh into the container?

[AngellusMortis]

It is not "new". It is over 4 years old. It was announced in 2019 at PyCon US. It is just since Github announced Codespaces that the idea of having a client/server architecture for editors/IDEs started taking off.

nvm might be "standard" for Node.js, but other tool chains are not so unified and/or have no solution for managing multiple separate versions and environments. People can be bullheaded all they want and just go "Micro$oft bad", but they are the only one trying to make a tool agnostic standard way of managing development environments at scale and the only one that is really automatable and maintainable by platform engineering teams in orgs.

And the "inferior experience" means, no LSP, no auto-completion, no linting, no running tests. If it comes down to having to support devs trying to use Sublime Text or just forcing them to use VS Code/JetBrains, the solution is just to not allow them to use Sublime Text. When your whole CI/CD and production chain is 100% containerized, the next logical step is just to containerize the dev environment too. If Sublime Text wants to go anti-Microsoft and boycott devcontainers because they made it, then that only hurts your paying and loyal users. As an organization, one less development environment to support means less work for us.

[Thom1729]

To be clear, I don't work for Sublime HQ and my opinions are my own.

I have no particular antipathy toward Microsoft. I'm merely observing that this is a “standard” that is written by one company, which is only fully implemented by that company's editor, and whose primary use case seems to be interfacing with that company's cloud services. I am not in a position to have an opinion on whether your company should switch from the established platform- and tool-agnostic solutions to a new solution that is not widely supported outside that one company's offerings. Maybe that's the right move for your company.

My doubts about the feasibility of implementing this in other editors stem not from any notion of an “anti-Microsoft” “boycott”, but because as you describe the system it sounds fairly contrary to the architecture of most text editors. It is possible that I misunderstand, and that the system could be implemented by third-party editors in a less intrusive fashion. If so, then I fully expect that other editors will eventually support it, including Sublime — just as Sublime has excellent support for LSP via the community-written LSP package. If not, then not.

[AngellusMortis]

https://survey.stackoverflow.co/2023/#section-most-popular-technologies-integrated-development-environment

Of the top 10 editors, 6 of the 10 support Remote Development in some capacity (either devcontainers specifically or Github Codespaces). You can argue devcontainers themselves support vim bringing the number to 7. Since vim is basically just configured through dotfiles which devcontainers can load automatically. It might also work with neovim as a result, but I am not familiar with neovim.

This is not 2019 when the feature was announced and only Microsoft was backing it. It is now clear that the concept of a remote development environment (via a container, or a network connection) is useful.

[Thom1729]

Can you clarify the support situation? I had interpreted your prior comment to mean that only VSCode fully supported the spec, and only JetBrains offered substantial incomplete support. Which other editors support the spec, and in what general degree?

[ntenney]

I wouldn't call devcontainers tool agnostic, since only vscode fully integrates with it. But there are plenty of truly tool agnostic ways of doing container based development. The simplest of these is simply to mount the local file system in a container and use your editor to edit on the local file system, and attach a terminal to the running container to issue commands as needed. That is truly tool agnostic as it can be accomplished with any editor. On top of that, the way that most of the "6 of top 10 editors" support remote dev like code spaces is to simply do something like sshfs to connect to the remote space, which can easily be accomplished in Sublime with plugins, or via command line mounting of the remote file system and then doing "local" filesystem edits using sublime. I also wouldn't say that vim supports remote container development because most users vim configs require plugins, which may or may not be available depending on the containers network configuration.