3 ms·

A CLI to quickly launch VSCode/cursor devcontainers

49 points by michidk 2y ago

ed_blackburn 2y ago
I am experimenting with dev containers at the moment. I am finding them very useful for setting up environments and they work as advertised. Where I am struggling is the poor support in the Jetbrain's suite and having to accommodate different editors. We need more tooling and editor plurality for dev containers to take off.
- Alifatisk 2y ago
  Have you tried Gitpod or Devpod for Jetbrains?
  - ed_blackburn 2y ago
    We are really happy with GitHub, that's our source control and CI platform: I think editors are fungible but not source control,ALM,CI etc. I hear your point though and I see how the loop is being closed with cloud providers hosting your code and editor so they can simplify deployment to their cloud. It's partially why I was surprised to see JetBrain's Fleet fall away, I thought it was their play at separating the editor FE and BE...
- ricoxicano 2y ago
  Have you considered the possibility that Jetbrain's users are left behind while devcontainers have already taken off?
  - sunaookami 2y ago
    Has it taken off though? It reeks like a semi open-source Microsoft product where the only goal is to lock you into VS Code.
  - ed_blackburn 2y ago
    Yes, I’m aware of the politics, but I’m not about to force developers to switch editors for a single feature. We’re seeing real competition again, with new entrants like Zed, and that’s a good thing—engineers should be free to use the tools they’re most productive in, whether that’s VS Code, JetBrains, Neovim, EMACS, Helix, or Zed. Tooling that claims to improve developer productivity should be editor-agnostic. If Microsoft can’t fully support that, an alternative standard will emerge—because, ultimately, locking developers in rarely works long-term. Besides, the VS Code golden age has passed. It’s well on its way down the enshittification ramp.
hombre_fatal 2y ago
Can someone describe what it's like to use devcontainers? Is it a last resort, like if your arch is so different from your project environment that you have to go so far as to develop inside a container? I hate even running local docker containers the second I want to do anything inside them. And that's the vibe I get when I read about devcontainers despite wanting to earnestly try it out at one point (I frankly couldn't figure it out back when I tried).
- thunky 2y ago
  They also allow you to package up and share your entire development environment and all the tooling you use with it. That means that someone coming into a project has nothing to setup on their local machine - runtimes, compilers, etc. You can use them for this reason without doing remote dev. But yes for remote dev you wouldn't even need to setup docker locally, and you're able to develop on a different architecture.
- mbreese 2y ago
  It’s like the entirely of the project is completely self contained. Your host system can be running anything and you don’t need to worry about installing tools on your system to get going. You also don’t need to worry about different dev environments for different projects. Is this a Go project and you don’t have the right Go tools installed locally? Not a problem, as it’s in the container. Do you have multiple node/js projects and you don’t want modules or tools to overlap? Each project has its own container. Do you work on Mac, but want to deploy on Linux? The container makes this work too. (This one is my primary usecase). With a devcontainer, I can work on my Mac without having to install dozens of homebrew packages. Better yet, I can work with others and it doesn’t matter what computer they use, as the dev environment is standardized. If you ever used Vagrant to work in a dev VM, it’s like that… but much faster to get started.
- kevmo314 2y ago
  I use them as a last resort. They're nice in theory but you'll lose your extensions (which you can configure but if you check it in you're imposing on everyone else...), bash history, and most debugging tools you have installed locally. Unfortunately, those are really "features" of being in a container and if you work around them it's kind of defeating the point of a container. They're helpful for cross-architecture debugging and serving as a source of truth that the build actually works on a dev machine but definitely the ergonomics leave a bit to be desired.
mbreese 2y ago
Authors blog post talking about this project: https://blog.lohr.dev/launching-dev-containers https://blog.lohr.dev/launching-dev-containers
bdcravens 2y ago
If you've already standardized on Docker Compose for development, is there an advantage to migrating to devcontainers?
- apearson 2y ago
  DevContainers allow for setting up your IDE with extensions, rules, and other configuration. They also support Docker compose so migration shouldn't be that bad
  - diggan 2y ago
    > DevContainers allow for setting up your IDE with extensions, rules, and other configuration. Are people sharing their editor configs with this? I thought it was a way of getting a development environment setup, but those shouldn't have editor extensions and configuration.
    - apearson 2y ago
      Yes, certain extensions and settings (formatting) go along with setting up the dev environment: https://containers.dev/supporting https://containers.dev/supporting
amluto 2y ago
I wonder if this could be adapted to run vscode, with a devcontainer, but in a sandbox? I want to see and interact with the vscode GUI, and I want vscode to be able interact with the container, but I do not want vscode to have any access to anything else that I don't explicitly grant. This includes my home directory and even my network. One approach might be to try to put vscode into the devcontainer or into another container. But it needs a hole poked for the GUI for for someone to do the plumbing to get the GUI to run in a sandboxed browser context, and I don't think MS makes this easy. (Note that vscode has no security model. If you connect vscode's normal frontend to a malicious backend, you are pwned, and this isn't even considered a bug.)
GNOMES 2y ago
Tooling looks useful, but still trying to understand Dev containers themselves. Why use one of these premade container images vs using a base image, adding extra packages/layers as needed?

49 points by michidk 2y ago

I am experimenting with dev containers at the moment. I am finding them very useful for setting up environments and they work as advertised. Where I am struggling is the poor support in the Jetbrain's suite and having to accommodate different editors. We need more tooling and editor plurality for dev containers to take off.

Alifatisk 2y ago
Have you tried Gitpod or Devpod for Jetbrains?
- ed_blackburn 2y ago
  We are really happy with GitHub, that's our source control and CI platform: I think editors are fungible but not source control,ALM,CI etc. I hear your point though and I see how the loop is being closed with cloud providers hosting your code and editor so they can simplify deployment to their cloud. It's partially why I was surprised to see JetBrain's Fleet fall away, I thought it was their play at separating the editor FE and BE...
ricoxicano 2y ago
Have you considered the possibility that Jetbrain's users are left behind while devcontainers have already taken off?
- sunaookami 2y ago
  Has it taken off though? It reeks like a semi open-source Microsoft product where the only goal is to lock you into VS Code.
- ed_blackburn 2y ago
  Yes, I’m aware of the politics, but I’m not about to force developers to switch editors for a single feature. We’re seeing real competition again, with new entrants like Zed, and that’s a good thing—engineers should be free to use the tools they’re most productive in, whether that’s VS Code, JetBrains, Neovim, EMACS, Helix, or Zed. Tooling that claims to improve developer productivity should be editor-agnostic. If Microsoft can’t fully support that, an alternative standard will emerge—because, ultimately, locking developers in rarely works long-term. Besides, the VS Code golden age has passed. It’s well on its way down the enshittification ramp.

hombre_fatal 2y ago

Can someone describe what it's like to use devcontainers? Is it a last resort, like if your arch is so different from your project environment that you have to go so far as to develop inside a container? I hate even running local docker containers the second I want to do anything inside them. And that's the vibe I get when I read about devcontainers despite wanting to earnestly try it out at one point (I frankly couldn't figure it out back when I tried).

thunky 2y ago
They also allow you to package up and share your entire development environment and all the tooling you use with it. That means that someone coming into a project has nothing to setup on their local machine - runtimes, compilers, etc. You can use them for this reason without doing remote dev. But yes for remote dev you wouldn't even need to setup docker locally, and you're able to develop on a different architecture.
mbreese 2y ago
It’s like the entirely of the project is completely self contained. Your host system can be running anything and you don’t need to worry about installing tools on your system to get going. You also don’t need to worry about different dev environments for different projects. Is this a Go project and you don’t have the right Go tools installed locally? Not a problem, as it’s in the container. Do you have multiple node/js projects and you don’t want modules or tools to overlap? Each project has its own container. Do you work on Mac, but want to deploy on Linux? The container makes this work too. (This one is my primary usecase). With a devcontainer, I can work on my Mac without having to install dozens of homebrew packages. Better yet, I can work with others and it doesn’t matter what computer they use, as the dev environment is standardized. If you ever used Vagrant to work in a dev VM, it’s like that… but much faster to get started.
kevmo314 2y ago
I use them as a last resort. They're nice in theory but you'll lose your extensions (which you can configure but if you check it in you're imposing on everyone else...), bash history, and most debugging tools you have installed locally. Unfortunately, those are really "features" of being in a container and if you work around them it's kind of defeating the point of a container. They're helpful for cross-architecture debugging and serving as a source of truth that the build actually works on a dev machine but definitely the ergonomics leave a bit to be desired.

mbreese 2y ago

Authors blog post talking about this project: https://blog.lohr.dev/launching-dev-containers https://blog.lohr.dev/launching-dev-containers

bdcravens 2y ago

If you've already standardized on Docker Compose for development, is there an advantage to migrating to devcontainers?

apearson 2y ago
DevContainers allow for setting up your IDE with extensions, rules, and other configuration. They also support Docker compose so migration shouldn't be that bad
- diggan 2y ago
  > DevContainers allow for setting up your IDE with extensions, rules, and other configuration. Are people sharing their editor configs with this? I thought it was a way of getting a development environment setup, but those shouldn't have editor extensions and configuration.
  - apearson 2y ago
    Yes, certain extensions and settings (formatting) go along with setting up the dev environment: https://containers.dev/supporting https://containers.dev/supporting

amluto 2y ago

I wonder if this could be adapted to run vscode, with a devcontainer, but in a sandbox? I want to see and interact with the vscode GUI, and I want vscode to be able interact with the container, but I do not want vscode to have any access to anything else that I don't explicitly grant. This includes my home directory and even my network. One approach might be to try to put vscode into the devcontainer or into another container. But it needs a hole poked for the GUI for for someone to do the plumbing to get the GUI to run in a sandboxed browser context, and I don't think MS makes this easy. (Note that vscode has no security model. If you connect vscode's normal frontend to a malicious backend, you are pwned, and this isn't even considered a bug.)

GNOMES 2y ago

Tooling looks useful, but still trying to understand Dev containers themselves. Why use one of these premade container images vs using a base image, adding extra packages/layers as needed?