Dev Containers

[abhibeckert]

Check for existing issues

• Completed

Describe the feature

A Dev Container is a system that runs your code and part of your development environment (Language Server, Unit Tests, Debugger, Build Scripts, etc) inside a container. Many people consider this a blocking feature, as it's arguably an industry best practice to manage projects with complicated dependencies.

Visual Studio Code has a great implementation of this feature. Essentially you describe your environment and dependencies in a .devcontainer directory filled with config files, and the editor spins up a container when you open the project - it only takes a few seconds and often needs. Your code and the majority of VSCode extensions will run inside the container.

This feature request has been previously discussed in #5347 Remote Development and is related to the collab feature, but it's not quite the same thing and should be tracked separately in the issue tracker.

If applicable, add mockups / screenshots to help present your vision of the feature

No response

[Moshyfawn]

• Related Add support for "remote development" #5347

[versecafe]

Getting started on this I'd love help from anyone who's interested, took a little bit to figure out GPUI, panel registration, and settings since they're not super documented but here's the branch, just got the basic UI for the panel up, starting on the actual logic using bollard

UI Example Very Early

Branch

https://github.com/versecafe/zed/tree/dev-containers

@abhibeckert Any opinions on how closely you think it should match VS Codes implementation, both in UI and in features?

[ConradIrwin]

@versecafe Thanks for taking a pass at this! This is one of the top features for people in the remote development alpha too.

For remote servers we ended up choosing to use a modal instead of a panel because the primary use-case of showing the list is to select one and open a new workspace (it didn't seem useful enough to show the list permanently to take up screen real estate all the time). Are there other use-cases that mean it's helpful to have this in an always-open panel while working on code, or should we add this to the cmd-shift-o dialogue too?

As a heads up, @maxbrunsfeld has been exploring ideas for a worktree based remoting feature, which is probably a better starting point than the current remoting feature (which installs a full zed on the remote host and communicates over the internet).

What are the next steps on this in your mind?

[chloerei]

One of the features I rely on in vscode is to enable extensions in the container. Since my host environment does not have dependencies installed, extensions may not work properly in the host environment.

For example, in devcontainer.json:

  "customizations": {
    "vscode": {
      "extensions": [
        "Shopify.ruby-lsp",
        "bradlc.vscode-tailwindcss"
      ]
    }
  }

[versecafe]

@chloerei Something like this maybe

zed-devcontainer.json

{
  "zed": {
    "extensions": [
      { "git": "https://github.com/versecafe/zed-groovy" },
      { "zed": "kotlin" },
      { "zed": "base16" }
    ],
    "lsp": {
      "rust-analyzer": {
        "initialization_options": {
          "cargo": {
            "features": "all"
          }
        },
        "procMacro": {
          "ignored": ["server"]
        }
      }
    }
  }
}

Extensions both from Zed directly or direct git URL for custom ones + LSP overrides

[ConradIrwin]

It probably makes most sense to just auto-install any extensions on the remote that are installed on the local and which are needed for the current filetype. That way you (shouldn't) have to think about it in the common case.

[abhibeckert]

It probably makes most sense to just auto-install any extensions on the remote that are installed on the local and which are needed for the current filetype.

No definitely not. Some extensions, e.g. anything providing intellisense, consume a lot of resources (RAM, CPU, Disk I/O…) which might crash hard on a low end virtual server.

I’ve also seen node extensions rack up a few hundred dollars in usage costs by installing node extensions in VSCode a production server which would automatically be allocated additional RAM/CPU cores when load was high. Node is perfectly happy to consume ridiculous resources automatically especially if you load a production environment that might have gigabytes of compiled JavaScript files in a cache directory.

[lattice0]

devcontainers are the reason I'm not on zed yet. waiting 🙏

[samstride]

It probably makes most sense to just auto-install any extensions on the remote that are installed on the local and which are needed for the current filetype. That way you (shouldn't) have to think about it in the common case.

Hmmm, if possible, it will be good to have a setting for auto-install local extension: on/off.

There are definitely situations where it will be good not to auto-install local extensions into devcontainer.

[maxbrunsfeld]

I think we can probably do something pretty targeted. In Zed, extensions expose a lot of static metadata about exactly what they provide. So we can just run extensions locally as normal, but when we detect for example that a particular language server extension needs to run on the remote host, we can copy just that one WASM binary over to the host, and run it there. We can probably upload it using the same SSH connection, so no need for the host to have internet access.

[quackerex]

@versecafe I am not sure if you noticed but there seems to be an open specification for dev containers. I reckon it would be best to follow that.

see - https://containers.dev

[lattice0]

devcontainers + web version would be AWESOME. Not even VS Code has remote web devcontainers. I miss that for development on my Galaxy Tab S9 Ultra

[deadmeu]

Jetbrains has also recently started supporting devcontainers (https://youtrack.jetbrains.com/issue/IJPL-65918/Implement-devcontainer.json-specification). Their implementation, however, may not be entirely accurate to the spec, as noted by this comment. Something to watch out for when this feature is being implemented.

[elliotblackburn]

As mentioned by @quackerex, it's an open specification now. There are already some tools which implement the spec which are editor agnostic, such as the CLI reference implementation. There's also DevPod which seems to have a GUI (I've not used it).

Those could be a way for someone to use Zed without giving up devcontainers for now. First class support would be incredible though, and the CLI project might be a good reference for the Zed implementation.

[forabi]

It would also be nice if Podman is supported out of the box. The VS Code implementation is pretty coupled to Docker and that comes with complexities when it comes to file permissions in rootless mode.

[drobbins-ancile]

This is the only missing feature that's preventing me from using Zed full time.

[axxyhtrx]

Orbstack + Zed devcontainers would be the best combo!

[lattice0]

I've been trying to use VSCode web on my android tablet and I have to say: basic things like mouse over errors won't work and VSCode team did not have interest to fix it. It's pretty broken. Also, it's been almost one year since I opened microsoft/vscode-remote-release#9059 and they don't seem to want to support it, and their extension is closed source so we cannot change it.

Basically is Zed had: web version that works on tablets, self hosted version (but maybe also online tunnel support like vscode), devcontainer support, I'd switch immediately and forever.

Thanks!

[andreytkachenko]

Consider Sunshine+Moonlight combo

[darltrash]

This is also necessary if you want to develop on an OS-Tree based system like Fedora Silverblue if not by running zed straight up inside toolbox, which afaik it doesn't actually work properly.

[imbev]

It would be ideal for Flatpak-packaged Zed to be able to use devcontainers with host podman.

[lattice0]

@andreytkachenko on Android, mouse on Sunshine+Moonlight is a very poor experience. I tried many solutions for vscode web version

[tidux]

This is also necessary if you want to develop on an OS-Tree based system like Fedora Silverblue if not by running zed straight up inside toolbox, which afaik it doesn't actually work properly.

Yeah the solution for that is typically Distrobox which is... not great. I actually switched my main Linux PC from Fedora Kinoite (Silverblue-KDE) to Gentoo because I was handbuilding so much of my dev envs anyway.

[nicraMarcin]

I'm also waiting for it.

[imbev]

@chloerei Something like this maybe

zed-devcontainer.json

{
  "zed": {
    "extensions": [
      { "git": "https://github.com/versecafe/zed-groovy" },
      { "zed": "kotlin" },
      { "zed": "base16" }
    ],
    "lsp": {
      "rust-analyzer": {
        "initialization_options": {
          "cargo": {
            "features": "all"
          }
        },
        "procMacro": {
          "ignored": ["server"]
        }
      }
    }
  }
}

Extensions both from Zed directly or direct git URL for custom ones + LSP overrides

Following the spec, I suggest the following:

{
    "build": {
        "dockerfile": "Dockerfile"
    },
    "customizations": {
        "zed": {
            "extensions": [
                "git+https://github.com/versecafe/zed-groovy",
                "kotlin",
                "base16"
            ]
        }
    }
}

[haliliceylan]

@chloerei Something like this maybe
zed-devcontainer.json

{
  "zed": {
    "extensions": [
      { "git": "https://github.com/versecafe/zed-groovy" },
      { "zed": "kotlin" },
      { "zed": "base16" }
    ],
    "lsp": {
      "rust-analyzer": {
        "initialization_options": {
          "cargo": {
            "features": "all"
          }
        },
        "procMacro": {
          "ignored": ["server"]
        }
      }
    }
  }
}

Extensions both from Zed directly or direct git URL for custom ones + LSP overrides

Following the spec, I suggest the following:

{
    "build": {
        "dockerfile": "Dockerfile"
    },
    "customizations": {
        "zed": {
            "extensions": [
                "git+https://github.com/versecafe/zed-groovy",
                "kotlin",
                "base16"
            ]
        }
    }
}

I highly recommend add version for extensions, which is not available vscode also causing some trouble.

[imbev]

I highly recommend add version for extensions, which is not available vscode also causing some trouble.

In that case:

{
    "build": {
        "dockerfile": "Dockerfile"
    },
    "customizations": {
        "zed@v0": {
            "extensions": [
                "git+https://github.com/versecafe/zed-groovy",
                "kotlin",
                "base16"
            ]
        }
    }
}

[mathroc]

the spec says :

Tool-specific configuration. Each tool should use a JSON object subproperty with a unique name to group its customizations.

so it can be whatever works for Zed in customizations.zed

[gintsmurans]

Just to add my two cents as I am also waiting for this in zed. This is how we are using devcontainer.json:

{
    "name": "External Services",
    "dockerComposeFile": [
        "../docker-compose.yml"
    ],
    "service": "develop",
    "runServices": [
        "develop"
    ],
    "shutdownAction": "none",
    "workspaceFolder": "/srv/app",
    "customizations": {
        "vscode": {
            "settings": {
                "python.defaultInterpreterPath": "/srv/venv/bin/python3",
                "python.languageServer": "Pylance",
                "python.analysis.typeCheckingMode": "strict",
                "python.analysis.autoImportCompletions": true,
                "[python]": {
                    "editor.formatOnSave": true,
                    "editor.defaultFormatter": "ms-python.black-formatter"
                },
                "python.analysis.extraPaths": [
                    "submodules/py-shared-lib"
                ],
                "python.autoComplete.extraPaths": [
                    "submodules/py-shared-lib"
                ]
            },
            "extensions": [
                "ms-python.python", // Python
                "ms-python.vscode-pylance", // Python autocomplete
                "ms-python.black-formatter", // Python formatter
                "github.copilot", // Github co-pilot
                "aaron-bond.better-comments" // To highlight some comments
            ]
        }
    }
}

[pascalbreuninger]

Disclaimer: I'm a maintainer of DevPod

DevPod just added support for Zed with the latest release. This doesn't apply zed specific settings like extensions and configuration to the workspace but it let's you build and run your devcontainers and then connect to them from Zed

[gintsmurans]

Disclaimer: I'm a maintainer of DevPod

DevPod just added support for Zed with the latest release. This doesn't apply zed specific settings like extensions and configuration to the workspace but it let's you build and run your devcontainers and then connect to them from Zed

Oh, this is interesting, will give it a try.

[ConradIrwin]

Thanks @pascalbreuninger!

For the rest of dev containers, configuration is still something I want to figure out – Zed's approach to extensions means it's relatively cheap to run whatever you have installed in the container, but I can see an argument for putting it in "vanilla mode" if you really don't want any language servers running.