Open metaskills opened 2 years ago
We want to keep this new CLI independent of VS Code, so an open
command would need a way for all editors to participate. Maybe an EDITOR_DEVCONTAINER
env variable could be used similarly to the commonly used EDITOR
env variable, but I'm not sure having an open
command just to invoke EDITOR_DEVCONTAINER
would then add much value.
That seems to make sense... when I looked at other proposed solutions to make VS Code & the CLI easier I got the impression that the image IDs might not match what VS Code's "Open Folder in Container..." would do. Do you think that is un-warranted? I have not confirmed if it was the case or not.
Also, did y'all have thoughts on where devcontainer open
should land? Maybe some VS Code CLI?
I think an open
command in the @devcontainers/cli
could provide support for many editors, like vscode or intellij. The preferred editor could be configured by the user in some kind of configuration file (as we do for git in the ~/.gitconfig
).
Initially, it could support vscode only. More editors could be added over time. Or even an generic implementation could also be added so that any editor can plug-in without having to be supported by @devcontainers/cli
before.
There's several hacks using code --folder-uri
to make your own open
command. For example, see my bash function implementation.
This definitely should have better support. Until I found that hack, I stayed on the version provided by the vscode-remote extension, which is rather buggy to say the least.
I was getting kind of tired of opening a new VS Code window and using the "Remote-Containers: Open Folder in Container..." command and was wondering if there was an easy way to do the same via the CLI. Eventually I stumbled on this thread which I've participated on as well.
https://github.com/microsoft/vscode-remote-release/issues/2133#issuecomment-1070823264
Not sure if this project would have a simple
open
command or not or where that would land?