Closed jrieken closed 5 years ago
For language servers, this would require new ways for the language server to get text documents over LSP from the client instead from the disk - what do you think about https://github.com/sourcegraph/language-server-protocol/blob/master/extension-files.md?
Is this going to be similar to Nuclide's remote dev support?
Re: #10547
I also have a use case for editable/saveable TextDocumentProvider
s, or similar functionality by some other means. I've written a plugin that decrypts data to a virtual document. This is useful by itself, but it would be nice to allow editing the plain text file and encrypting it back upon save. I could probably implement this by decrypting to a temporary file instead and letting the user edit that, but having the functionality in TextDocumentProvider
would make my implementation cleaner for sure.
FYI - For August we will explore to hook into our search infrastructure. That means support for searching for and in files. Work has started here: #32549. Everyone please join the discussion.
is this being added, i use nuclide.io for remote dev but i want something good for the same with Angular 2 in VS code?
@paulchill Eventually? #34218 is the next iteration of this idea, and you should follow the "remote" label if you want to track its progress.
Closing this as the file system provider api has been shipped
@jrieken This issue was pointed to by @roblourens in response to #47199, but it seems to be a bit different from this. Will this allow VSCode to access the remote environment where the code lives, including compilers, debuggers, .vscode, .git etc.?
@jrieken @roblourens @mjbvz Could this be reopened?
As mentioned above, the idea behind this feature request is the ability to use a remote developer environment as if it was running locally (but all changes and the environment is remote). It is not about being able to work locally with a remote file system. This is similar to Live Share except the remote environment (which could run without a window manager) is something we ssh into instead of it being shared with us.
Ok, understood. Thanks for clarifying.
π―This would be very useful and create a better user experience for organizations that do development on remote machines and are typically limited to vim, emacs, x11 forwarding or vnc, or for development environments which are located within Docker containers.
Another use case of headless is companies pair program, and that may be making pair programming possible today using tools like tmux, vim, emacs, and vnc. Would it be possible to expand the scope of this issue or at least keep in mind the possibility of there being multiple gui vscode's talking to a single remote headless vscode? I realize that probably has it's own set of challenges beyond a single gui driving the headless vscode, but maybe that's something that can be kept in mind to keep it a possibility.
I deleted an earlier post (assuming beyond scope) that suggested it could help WSL development scenarios, which is ideologically a "no xclients" fly zone right now for reasons.
For all of you who really would need such a feature, after a long search I found a way to develop on a remote machine. Even though it is very far from perfect, better than nothing: https://nuclide.io/
For developers if you need inspiration how to make an easy to use remote dev process: https://nuclide.io/docs/features/remote/
Unfortunately until vscode supports something similar, I am stuck with atom.
We use this daily in our company. Works brilliant bar some remote linting issues with Typescript and Php.
On Mon, 15 Oct 2018, 10:45 Michael F., notifications@github.com wrote:
For all of you who really would need such a feature, after a long search I found a way to develop on a remote machine. Even though it is very far from perfect, better than nothing: https://nuclide.io/
For developers if you need inspiration how to make an easy to use remote dev process: https://nuclide.io/docs/features/remote/
Unfortunately until vscode supports something similar, I am stuck with atom.
β You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Microsoft/vscode/issues/29194#issuecomment-429777250, or mute the thread https://github.com/notifications/unsubscribe-auth/AGqgfF7HZ_IuTajRIF-J6eVc2xsDTYoKks5ulFklgaJpZM4OA9ez .
I would love to see this feature for VS Code.
Please try and make the server installation easy, with some focus on Linux. I personally found the Nuclide installation very painful (for Linux). Docker containers could ease this pain, but it would still be great to get a frictionless installation process. I believe that it's crucial to adoption and the success of this feature.
This would be a wonderful feature. I am wondering if jupyter notebook server is a good idea for vscode to access the remote file system, as it provides some basic functions of file system, like browsing files in a folder, creating files/folders and editing plain text files. Is it possible for vscode connecting to the jupyter server and take care of the file system provided? Then just using port forwarding, local users can access the remote file system. It is very useful when users do not have root access for remote server, cannot mount the remote file system and have a jump server, which can be quite common for shared computation center. Also it may be a good idea for cross platform access.
Since I found out facebookarchive/nuclide has been sunset β Code is my refuge and first-class support for remote development (hopefully at par with what Nuclide offered) would be a life-saver.
@jrieken Would you mind editing the initial issue description? It seems like the scope of this issue has changed over time. I wrongly dismissed this issue as not the client-server architecture I was looking for, because the description mostly sounds like a remote file system.
I got here looking for a solution for a - IMHO typical - python π dev scenario: we have our interpreter (and all the dependencies) inside a docker π¦ image. I'd love to pick as python interpeter the one of the running docker, instead of recreating it in a virtualenv
on my laptop :)
The problem is that the use case needs to cover also containers that could run on a remote machine (I.e. On a Kubernetes node Pod)
Is anything like this available in alpha? We're using Atom with Nuclide but tbh VSCode is where it's at, especially for frontend TypeScript development.
I discovered this recently: https://github.com/codercom/code-server
I discovered this recently: https://github.com/codercom/code-server
Will vscode officially support like this?
Been using mutagen.io. Not perfect, but it works pretty well.
@jrieken Any progress or official response? I find the code-server is quite usable, but the keybinding is annoying, e.g. Ctrl+Shift+P will open print dialog, etc.
During my practice of remote development, there are basically 2 types of scenarios.
Based on my experience, I'll stick to code-server for now.
Since Microsoft have invented Language Server Protocol and Debugger Adapter Protocol for good reason, maybe it is time to invent Editor Server Protocol :).
I was some work being done on implementing network-based IPC. Haven't seen an official statement or tracking issue for it, but I guess we're getting there.
My personal problem with remote development is that I often have to run heavy things that eat up the battery very quickly (might run an occasional fork bomb even). For this reason, I'd like to have a way of running the editor, language servers, extensions and so on remotely (quite often a vs code glitches and and up as the fork bomb), and only the user-facing UI portions (like the editor window) to run locally.
So far, based on my lurking in the vscode code base, it's already build with that kind of isolation in mind, so what's left is just addressing the use case: making things work over the network and implementing interfaces for the editor to allow connecting to remotely executing instances.
PS: all my use cases do not involve any kind of cloud, and it'd be very limiting it the resulting solution were implemented with some closed-source backend (I'm looking at you Azure). Added this remark cause Microsoft is big corporation that's biased to force their other services is such a way.
I find the code-server is quite usable, but the keybinding is annoying, e.g. Ctrl+Shift+P will open print dialog, etc.
@cloudhan, to solve this just open code-server in Chrome as an application in a separate window (requires Chrome >= 73): "three-dots menu" in the upper-right corner -> More tools -> Add to desktop, set "Open in window".
I don't really want to use Chrome for development - I'm more interested in something like Nuclide but officially supported and developed by the VSCode team if it exists.
@ARMATAV, for an end user there are no visible differences between something run in a separate Chrome window and a separate local application like vscode. You never see what you are working in browser.
The one thing why code-server is better for me than some client-server API inside vscode is what the way it works is very similar to the way vim works on a remote server: vim over ssh inside terminal vs vscode over https inside browser.
i guess there will be a new alternative to code-server pretty soon π
@OneCyrus Can you expand on that? What will the alternative be?
@aleksey-mashanov there are clear and obvious differences between a local application and a Chrome tab - isolation, distraction and performance are a few.
Also it's pretty scuffed to run the application inside of Chrome, to be honest with you, it's a hacky workaround for to make do since we don't have a built-in officially supported solution.
I was inquiring if there was a Nuclide for VSCode, a lot of big companies and startups use remote development - but there is not, so we've learned.
@OneCyrus Can you expand on that? What will the alternative be?
https://github.com/Microsoft/vscode/issues/71830
first paragraph and git commit history should tell you a lot. should be announced at build next week.
Is there a nightly build or something?
I hope it is more than WSL support and will run everything via SSH to a remote system, especially file access and the LSP, e.g clangd. WSL isn't exactly remote development.
I assume extensions would need to be deployed on the remote system somehow, otherwise both the LSP extension and vscode would need to be 'remote-aware'. Which is also possible - but then we'd be waiting for someone to write a 'remote clangd LSP' extension.
i'm confident in the vscode devs. they are doing great work!
it looks like the handling of remote extensions is already baked in: https://github.com/Microsoft/vscode/blob/296fa84d8de6d63edc8417f9a3af2824118cc797/src/vs/workbench/contrib/extensions/node/extensionsWorkbenchService.ts#L555-L560
Closing π pls see https://code.visualstudio.com/blogs/2019/05/02/remote-development, please give it a try.
Wow, this looks very comprehensive and a potential game-changer for a lot of people! I expect you'll see a step change in VSCode usage as a result. Thanks VSCode devs!
This is implemented beautifully. Great work everyone!
Finally π
Works very well so far. The suggested extension for C++ code in this scenario should perhaps be vscode-clangd rather than the MS cpp extension. Although that may be subjective/political so only a minor comment. Otherwise an awesome enhancement - there is no other IDE offering this functionality properly.
π Alpine Linux not supported......
When will the remote development be available in stable versions?
Yes, when will it be released? Not really a closed issue for vscode if it isn't available.
Insider builds don't count.
Are there any plans to support Alpine-Linux?
Remote development describes a setup in which VS Code is used to edit files that reside on a different computer which file system cannot be mounted. A server that only offers FTP is an example of such a setup.
The following features should be supported for good dev experience
The goal is to enable remote development via extensions, so new provider APIs are required to allow 3rd parties to integrate into more pieces of our system. Similar to #29025 we start with assessing how many assumptions are backed into our system and how we can make it aware of having multiple sources of truth, e.g. multiple search result providers, etc, etc.