-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
Add support for "remote development" #5347
Comments
This is a feature I'd love to see built into Zed. It even think it would be be neat if you could remote into some server and do the same collaborative editing there as well, although I don't know how often that would be used - maybe in the context of "fighting fires."
OT, but I wonder if this has improved significantly since I tried it last - it was super clunky and heavy handed when I first tried it. I much prefer how VS Code's works, it is a lot more simple. |
I don't think it's off-topic - in fact having this work smoothly and seamlessly is a major part of this feature. I haven't used Gateway, but their previous remote development solution (which involved rsyncing files between machines) was also super clunky (especially when the host was Windows and symbolic links were involved). VSCode really knocked it out of the park with the remote developer extension and it should be the standard to aim for and improve upon. |
I imagine good collaboration tools would be really useful in this space (I've previously had to collaboratively fight fires over a mix of slack and zoom and other tools), however there are also potential security concerns as anyone connecting to Zed for collaboration would have the same access to the host as the user that ran the Zed process (which may not be themselves). You don't want people connecting to Zed 'server' that is running as sudo (to fight fires on a file that requires admin priv to edit), and then have connecting users be able to open a shell in the remote terminal as root and do things. |
I was holding back on this feature, but now that it is out here, I'll also jump in. 😅 At the time of the Xray experiment, one mind-blowing feature was the ability to spin up the editor in headless mode. If I recall correctly, this mechanism was the backbone of the editor's web version. Reading through Discord, using the editor from the browser (i.e. the web version) is on the roadmap, so I hope to see this capability resurface. 😀 But I also agree with @imron; such a feature should be paired with (granular) users' permission management. Not sure if this goes outside of Zed scope's, though. |
I'd also love to see this. Btw this format in the CLI would be fantastic: zed user@host:path/to/project vs code's format is very strange by comparison: code --remote ssh-remote+workspace I can understanding adding a flag though, esp if e.g. you don't specify zed host # yeah not enough context
zed user@host # probably ok if you don't mind the inconsistency of conditionally allowing --ssh to be omitted
zed --ssh host # 💪
zed --ssh host:path/to/project # 💪
zed --ssh user@host:path/to/project # 💪 (totally understandable to require the --ssh flag) |
+1 to this, it's definitely a must for me because of WSL2 - which is currently the only way to have a decent development environment on Windows for non-MS stuff. |
The discussion seems focused on launching zed from the local machine to edit a remote file. As a user of rmate, then rsub, then ratom (well, maybe I renamed it ratom), I have the following: Would like to suggest adding a feature that is equivalent to rmate/rsub for zed, i.e. the ability to trigger a local zed from a remote machine to edit a remote file. |
I believe "remote development" is not only about editing files of a remote machine but also connecting to an LSP server running on the remote machine. As far as I know, very few LSP servers allow clients to connect to them via TCP, so maybe an additional forwarder program is required to be installed in the remote machine. As a person who comes from the NeoVim world, there are already something like distant and distant.nvim. Since |
Most important for me would be to remote into a container from a local Dockerfile or docker-compose. Same functionality as with vscode's dev containers. IMHO this is much better than simple SSH. |
Adding a +1 vote to this but with a little context. I have a workstation that I do most of my actual programming on, which I access from various different machines as a "frontend" to that workstation. I've always really enjoyed VSCodes support for this exact scenario and how seamless and easy to setup it is. Would love to see this implemented in this editor. One thing to note however is that the workstation is Linux based and most of the machines I use as "frontends" to that workstation are macOS based, so this might involve making the editor work on Linux as well. |
I use this feature everyday with VSCode as I am having my source in a remote computer, then when I tried Zed and it lack of this feature, I cannot experiment any further. Please adding this feature as it is very useful. |
I love this feature in vscode, because it is a pain to unify your own development environment on different computers, by remote development, I can start development on any new machine by install a vscode, even on some computers with extremely low configuration. |
This is a blocker to me regularly using zed. I almost always use vscode remote developing from my laptop to my desktop at home, so it would be disruptive to change this workflow to use zed. If this feature was supported, then I would definitely switch to use zed as a primary editor when using my low end MacBook Air. |
I'll also chime in with some additional context around this feature. For my use case (and others who work with HPC) almost none of our development is done locally. VSCode is the de facto standard due to the remote development tools. I know that JetBrains also has some remote development tools although I'm not too familiar with them. It would be great to see another editor that could support this use case and it seems Zed might be uniquely positioned to pull off an amazing user experience given the infrastructure built around collaborative editing. Excited to see what can come from this! |
+1 for remote lsp connection, I really like docker dev environments for keeping host machine clean |
Remote connection is also a big blocker for me using zed. Keep up the great work! |
+1, I use remote env everyday. It could be amazing to have this feature in Zed. |
Supporting devcontainers will open up a lot of possibilities, including easy integration with developer tools, like newly launched DevPod, which supports launching development environments locally or on the cloud platform of your choice. |
Launching a whole headless zed on the remote sounds like a good solution - it would trivially allow for remote language servers without them having to support TCP. And remote language servers etc integrations in the correct target environment would make life way, way easier than trying to approximate something similar locally with SSHFS. I occasionally write code where some dependencies are simply not available on mac, so every file that uses those upsets the language server. |
Sadly can't use zed in its current state because our entire development is done via VSCode devcontainer. |
+1. Please please please make the remote development feature happen. |
+1 for remote connection |
lapce support SSH and WSL remote development |
The remote dev in Lapce looking interesting but the editor itself is really in its early days. Even the basic core editing features aren't there (find & replace, bookmarks etc), no way to use as a daily driver. Though Zed is not far ahead in this department either :( Wish the devs first implemented basic editing before taking on the fancy complex colab features. |
Zed puts all required file in the user home directory too. No crap everywhere. |
@tinyaustralia Disagreeing or providing critical feedback are both fine, but the way you are saying things is not. This is your one formal warning of being in breach of our Code of Conduct. |
Sure, but he makes an important point. This feature has nothing to do with collaboration. In VSCode I almost exclusively use it to connect to localhost (in a container or virtual machine). Also - when I do want actual remotes shared, I’ll use 1Password or KeePass for that. Something with E2E encryption and robust security. |
sure, and no one has issues with that part, if you read the release notes, it links to https://zed.dev/docs/remote-development and there it says:
So it's likely a shortcut they took to get the feature working, and they are planning to make it work without going through Zed servers |
This comment was marked as abuse.
This comment was marked as abuse.
The feature itself is in beta and, as described on the docs page, the intention is to have no sign-in requirement for the full release. It's very clear. You don't have to use it before this is implemented. The words you used (which, btw, are not removed - you can click your comment to show it) are not kind, empathetic or respectful. Whether or not you directed them at the product or project or individuals is immaterial. The simple fact is that humans are building zed, and that kind of language makes its way back to those humans. Nobody is threatening you and nobody is going to hold it against you if you apologize and move on. Anyways, I agree with your point. I cannot use zed for anything real until the remote dev feature uses direct peer-to-peer communication. I'm pleasantly surprised at how fast the zed team has gotten linux and remote dev up and running, great work! |
This comment was marked as abuse.
This comment was marked as abuse.
|
What still needs to be done before this is closed? Is there a kanban somewhere? |
I have used the remote development feature for a week. I'll start with the positive feedback, since I like this feature as-is.
As for negative feedback,
Overall, I agree with the other comments. The feature request seems satisfied. I haven't felt the need to use VS Code this week. |
I look forward to using a peer-to-peer connection between the editor and remote machines 👍 . |
+1 Is p2p remote mode under development? 🥰 |
Sorry my understanding but what is peer to peer remote mode? |
The current implementation relies on connections to Zed's servers, meaning that it can't be used on remote machines that don't have access to the internet. |
SSH could solve that, as I do for VSCode web, but UDP hole punching with the initial 'handshake' only over zed servers would be awesome and fast
Enviado via Proton Mail para Android
…-------- Mensagem original --------
Em 26/08/2024 14:16, nrclark escreveu:
>>> I look forward to using a peer-to-peer connection between the editor and remote machines 👍 .
>>
>> +1 Is p2p remote mode under development? 🥰
>
> Sorry my understanding but what is peer to peer remote mode?
The current implementation relies on connections to Zed's servers, meaning that it can't be used on remote machines that don't have access to the internet.
—
Reply to this email directly, [view it on GitHub](#5347 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ABSTHAIT2XTDS4ON4HEPR2TZTNPG5AVCNFSM6AAAAABCJF5UZ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJQGY4DKNRWHA).
You are receiving this because you commented.Message ID: ***@***.***>
|
+1 for working inside docker containers. We use Dev containers extension to work inside docker machines, this way we are having the same environment on every dev instance and very much the same in prod. This also speeds up file change observers quite a lot. |
I have a question, why the remote development need the login on linux? |
How do we forward port, as it's such an essential feature for remote development. |
@arifzeeshan until we have port forwarding integrated, you can run from the command line. if you have a web app at python3 -m http.server 8000
# this is running in your_ssh_host you can forward that port with: ssh -N -L 9000:localhost:8000 your_ssh_host
# this runs in your local machine Then open your local browser at You can pass |
Integration with DevPod could be favourable to get out of the Microsoft core of the devcontainers ecosystem. Did someone already have a shot at sketching how such an integration could look like, implementation-wise? |
@almereyda I'm a maintainer of DevPod and opened up #15070 a while ago to integrate zed into DevPod. There's actually not much that's missing, just a way to reliably let Zed know about which SSH connection to use |
This shipped in v0.159.5 that just hit stable. Thanks for your encouragement on building this, and we will continue to refine things as needed – please file new issues if you encounter bugs! |
@ConradIrwin I don't see a mention of containers like in this issue. Are containers supported as well? |
containers are being discussed in a separate issue #11473 |
Hi, I can't seem to find any extension or support for simply connecting to a server via FTP or SFTP. Is support for these protocols still being added or is there an extension out there that I am not aware of that someone could suggest? Any assistance would be appreciated, thank you. |
Fantastic news! I remember creating this ticket back when Zed was still in invite-only beta and it's great to see it finally come to fruition. Thanks everyone who contributed for all your hard work. Great blog post linked in the release notes too. |
@almereyda Quick update on DevPod support: We've just released v0.6.0 which adds Zed as an IDE |
Visual Studio Code has a killer feature, "Remote Development", which allows you to remote in to another machine or a docker container, and develop on the remote machine/container as if the entire directory structure and dev environment (including terminal shell) was local.
It would be great to eventually see this feature in Zed, and even if Zed doesn't support this in version 1, it's a compelling enough feature that it would be worth laying to groundwork early on to support it, especially while you're still figuring out the internal api for the editor and how pieces fit together.
For some anecdotal feedback on the usefulness of this feature, in my current role (C++ dev at a large enterprise), for various business reasons our choice of IDEs is more or less limited to VSCode or CLion.
Since I joined and started showing people how the Remote Dev feature of VSCode works, I have seen about a dozen diehard CLion fans switch to VSCode (despite CLion being a better IDE for C++ development) simply because the Remote Development feature works so well and our development process involves a lot of remote development - we have company issued windows laptops, but the software we develop is linux-based and development happens in a mix of docker containers, virtual machines, wsl2 and remote linux instances.
VSCode with the Remote Development extension makes this really easy to deal with and devs will put up with reduced capability on the C++ IDE side of things, for the superior remote development support.
This feature is so useful that Jetbrains recently revamped their entire approach to remote development with Jetbrains Gateway to have something similar.
Anyway, just wanted to put this out there as something to consider, because I guess it will be easier to make architectural changes needed to support something like this earlier rather than later.
The text was updated successfully, but these errors were encountered: