Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dev Containers #11473

Open
1 task done
abhibeckert opened this issue May 7, 2024 · 32 comments
Open
1 task done

Dev Containers #11473

abhibeckert opened this issue May 7, 2024 · 32 comments
Labels
enhancement [core label] network Network connectivity issues, protocols and services support potential extension Functionality that could be implemented as an extension (consider moving to community extensions) remote dev Feedback for remote development servers

Comments

@abhibeckert
Copy link

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

@abhibeckert abhibeckert added admin read Pending admin review enhancement [core label] triage Maintainer needs to classify the issue labels May 7, 2024
@Moshyfawn
Copy link
Member

Moshyfawn commented May 8, 2024

@Moshyfawn Moshyfawn added potential extension Functionality that could be implemented as an extension (consider moving to community extensions) network Network connectivity issues, protocols and services support remote dev Feedback for remote development servers and removed triage Maintainer needs to classify the issue labels May 8, 2024
@JosephTLyons JosephTLyons removed the admin read Pending admin review label May 9, 2024
@versecafe
Copy link
Contributor

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

image

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
Copy link
Member

@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
Copy link

chloerei commented Jun 7, 2024

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
Copy link
Contributor

@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
Copy link
Member

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
Copy link
Author

abhibeckert commented Jun 7, 2024

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
Copy link

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

@samstride
Copy link

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
Copy link
Collaborator

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
Copy link

@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
Copy link

lattice0 commented Jul 9, 2024

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
Copy link

deadmeu commented Jul 9, 2024

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
Copy link

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
Copy link

forabi commented Jul 11, 2024

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
Copy link

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

@axxyhtrx
Copy link

Orbstack + Zed devcontainers would be the best combo!

@lattice0
Copy link

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
Copy link

Consider Sunshine+Moonlight combo

@darltrash
Copy link

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
Copy link

imbev commented Oct 12, 2024

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

@lattice0
Copy link

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

@tidux
Copy link

tidux commented Oct 16, 2024

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
Copy link

I'm also waiting for it.

@imbev
Copy link

imbev commented Oct 20, 2024

@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
Copy link

@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
Copy link

imbev commented Oct 31, 2024

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
Copy link

mathroc commented Oct 31, 2024

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
Copy link

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
Copy link

pascalbreuninger commented Nov 15, 2024

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
Copy link

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement [core label] network Network connectivity issues, protocols and services support potential extension Functionality that could be implemented as an extension (consider moving to community extensions) remote dev Feedback for remote development servers
Projects
None yet
Development

No branches or pull requests