You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Having a remote interpreter also helps when the remote machine already has a functional Python environment - possibly managed by someone else - which you don't want to/can't replicate on your local machine.
Copied from original issue: DonJayamanne/pythonVSCode#123
This is a great suggestion. The architecture of VSCode and the extension supports this. However this would require a lot of effort, primarily in two parts. One would be to sync the two environments and the other would be the creation of a proxy component that sits on the server to manage all of the comms and surely enough this would have to be developed in python.
However, this would require weeks if not longer to build. But something that I will most definitely explore as a side project.
Thanks for accepting this RFE. I was trying to add this feature myself, but the lack of knowledge of VSCode related stuff and other priorities forced me to put that project aside for the time being.
When I logged the ticket, I had the following use case in mind:
Remote server has a fully configured Python environment, which is more or less identical to the deployment setup.
The developer workstation may have Python installed, but it doesn't have the fully configured environment. While it is possible to build a virtual environment containing the required modules in many cases, some modules don't work cross-platform, or are hard to compile. In any case, it is always preferable to development using an environment that is similar, if not identical, to the deployment environment.
The development and deployment environments may even be running different operating systems.
As a result, linting, code-completion etc don't work as expected and end up causing more trouble than helping. A workaround is to run VSCode in a VNC session, or using X forwarding. In both cases, responsiveness of the UI is a function of network connectivity/load.
Originally, I had imagined that it will be implemented by running commands on the remote machine over SSH - that is what PyCharm does. Not sure if they maintain the connection as long as the IDE is open.
Using SSH ensures that you don't have to worry about things like authentication, managing a daemon on the remote machine etc. But using SSH means assuming that the client has a working SSH client - something you can't assume about Windows clients. I suspect PyCharm may be using its own SSH client - something I don't think is trivial to implement.
Your idea of using a socket server on remote machine seems like a good one. I don't particularly care for which language it is implemented in. Python would be ideal, since we are anyway assuming that python is installed on the remote machine. But I am fine with NodeJS as well. As long as the protocol is open, someone can always implement a python version later.
install a python package on the server
I assume you meant - install a python package on the remote which is then run as a daemon listening for requests from VSCode. Let me know if that is not the case.
I assume you meant - install a python package on the remote which is then run as a daemon listening for requests from VSCode. Let me know if that is not the case.
Yes, you are right. Will try to start with the node daemon, and later move it to a python daemon.
I'll raise my hand for this. Our whole dev team formerly relied on vagarant and currently relies on docker to do all of our development. Specifically during development, we use docker-compose to ensure all of the devs are running the same environment.
Today we use Anaconda + Sublime. I have been exploring Visual Studio Code for Python development and something similar is a must. This looks to be where it will originate from if it is to be. I can't thank you enough for even discussing it.
In our docker development case we just start up a new container that has the anaconda remote server on it. It gets the volumes from the django application, so it has access to all of the code currently running:
We also deploy on docker, so if this were a: We need to debug a running server we would end up doing something similar, just attaching the container and disposing of it when done. From that point of view I have absolutely no issue with this workflow:
- Install nodejs on the remote server
- Install a npm package (nodejs module)
- Start a socket server on this target server
I am also aware that not everyone uses Docker. I only mention the Docker use case here for those that may also depend on it. Naturally every deployment would differ and have different needs.
We are going to lock this issue as no one has a convenient work-around to share with people at the moment and to keep notifications down to just to updates we may share in the future.
I will say that we are actively working on a design to solve this with the VS Code team itself. I can't give an ETA since this is a cross-team collaboration and the work isn't finished yet, but please rest assured we are not ignoring this feature request.
Hi folks, we are closing this as support for remote Python interpreters is enabled by the new Visual Studio Code Remote extensions we are unveiling today at PyCon!
Reacted by Lam Nguyen, Satyen Rai, Kye Russell, Vadim Sentyaev, Jimmy Ye, François Steinmetz, elonzh, Mehdi OUAZZA, Igor Gorschal, Ziqiang Feng and 3 more
Reacted by Lam Nguyen, Satyen Rai, Kye Russell, Vadim Sentyaev and Tomoki Hayashi
Reacted by Mikalai Radchuk, hendrics, Olle Vidner, Santiago Fraire Willemoes, Lam Nguyen, Satyen Rai, Kye Russell, Liam, Hannes Ljungberg, Xie Chenhong and 15 more
Reacted by Lam Nguyen, Vadim Sentyaev, Felipe Ojeda, Yoz Grahame, Nirfse, Tomoki Hayashi and Petr Shypila
Reacted by Lam Nguyen, Simrun Basuita, Satyen Rai, Vadim Sentyaev, Ziqiang Feng, Pieter, Nirfse and Tomoki Hayashi
Awesome! Although my workflow has changed significantly since I opened this ticket — and I write more Java than Python these days — I am looking forward to trying this out! Thanks for implementing this!
Activity
DonJayamanne commentedon Nov 13, 2017
This is a great suggestion. The architecture of VSCode and the extension supports this. However this would require a lot of effort, primarily in two parts. One would be to sync the two environments and the other would be the creation of a proxy component that sits on the server to manage all of the comms and surely enough this would have to be developed in python.
However, this would require weeks if not longer to build. But something that I will most definitely explore as a side project.
DonJayamanne commentedon Nov 13, 2017
From Satyen Rai (@satyenr) on May 18, 2016 11:51
Thanks for accepting this RFE. I was trying to add this feature myself, but the lack of knowledge of VSCode related stuff and other priorities forced me to put that project aside for the time being.
DonJayamanne commentedon Nov 13, 2017
Todo: Add support for docker containers as per #179
DonJayamanne commentedon Nov 13, 2017
Suggestions for #183
DonJayamanne commentedon Nov 13, 2017
Lei LI (@vbem), Satyen Rai (@satyenr) , Satyen Rai (@satyenr), Nuno Diogo da Silva (@nffdiogosilva)
Hi everyone, I would like to re-visit this to understand the requirements and the constraints.
Here are some of the environments (usages):
Requirements:
One possible solution I'm thinking of is:
This is the easiest solution and quickest to implement.
However, this requires the installation of:
Would this be acceptable?
The only other solution is the following one. However this would take a lot longer to develop and implment:
DonJayamanne commentedon Nov 13, 2017
From Satyen Rai (@satyenr) on October 4, 2016 9:12
When I logged the ticket, I had the following use case in mind:
As a result, linting, code-completion etc don't work as expected and end up causing more trouble than helping. A workaround is to run VSCode in a VNC session, or using X forwarding. In both cases, responsiveness of the UI is a function of network connectivity/load.
Originally, I had imagined that it will be implemented by running commands on the remote machine over SSH - that is what PyCharm does. Not sure if they maintain the connection as long as the IDE is open.
Using SSH ensures that you don't have to worry about things like authentication, managing a daemon on the remote machine etc. But using SSH means assuming that the client has a working SSH client - something you can't assume about Windows clients. I suspect PyCharm may be using its own SSH client - something I don't think is trivial to implement.
Your idea of using a socket server on remote machine seems like a good one. I don't particularly care for which language it is implemented in. Python would be ideal, since we are anyway assuming that python is installed on the remote machine. But I am fine with NodeJS as well. As long as the protocol is open, someone can always implement a python version later.
I assume you meant - install a python package on the remote which is then run as a daemon listening for requests from VSCode. Let me know if that is not the case.
DonJayamanne commentedon Nov 13, 2017
Satyen Rai (@satyenr)
Yes, you are right. Will try to start with the node daemon, and later move it to a python daemon.
Finally, an open protocol does exist today:
https://github.com/Microsoft/language-server-protocol
Again, implementing this will be done at a later stage.
DonJayamanne commentedon Nov 13, 2017
DonJayamanne commentedon Nov 13, 2017
DonJayamanne commentedon Nov 13, 2017
DonJayamanne commentedon Nov 13, 2017
From @aventurella on November 28, 2016 14:24
I'll raise my hand for this. Our whole dev team formerly relied on vagarant and currently relies on docker to do all of our development. Specifically during development, we use docker-compose to ensure all of the devs are running the same environment.
Today we use Anaconda + Sublime. I have been exploring Visual Studio Code for Python development and something similar is a must. This looks to be where it will originate from if it is to be. I can't thank you enough for even discussing it.
In our docker development case we just start up a new container that has the anaconda remote server on it. It gets the volumes from the django application, so it has access to all of the code currently running:
We also deploy on docker, so if this were a: We need to debug a running server we would end up doing something similar, just attaching the container and disposing of it when done. From that point of view I have absolutely no issue with this workflow:
I am also aware that not everyone uses Docker. I only mention the Docker use case here for those that may also depend on it. Naturally every deployment would differ and have different needs.
115 remaining items
clumsykun commentedon Sep 21, 2018
nffdiogosilva commentedon Sep 24, 2018
woile commentedon Sep 24, 2018
KyeRussell commentedon Sep 24, 2018
brettcannon commentedon Sep 24, 2018
We are going to lock this issue as no one has a convenient work-around to share with people at the moment and to keep notifications down to just to updates we may share in the future.
I will say that we are actively working on a design to solve this with the VS Code team itself. I can't give an ETA since this is a cross-team collaboration and the work isn't finished yet, but please rest assured we are not ignoring this feature request.
qubitron commentedon May 2, 2019
Hi folks, we are closing this as support for remote Python interpreters is enabled by the new Visual Studio Code Remote extensions we are unveiling today at PyCon!
Learn more at...
VS Code Blog: https://code.visualstudio.com/blogs/2019/05/02/remote-development
Python Blog: https://devblogs.microsoft.com/python/remote-python-development-in-visual-studio-code/
If you are at PyCon stop by our booth for a demo.
satyenr commentedon May 3, 2019
Awesome! Although my workflow has changed significantly since I opened this ticket — and I write more Java than Python these days — I am looking forward to trying this out! Thanks for implementing this!