Related #5347

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?

@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?

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"
      ]
    }
  }

@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

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.

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.

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

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.

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.

@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

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

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.

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.

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.