RFE: Support Remote Interpreter

[DonJayamanne]

From @satyenr on May 13, 2016 3:37

The ability to run code on a remote machine is awesome. You can develop on a Windows PC or a Mac while running and debugging on a remote Linux server. PyCharm supports such a feature - https://www.jetbrains.com/help/pycharm/2016.1/configuring-remote-python-interpreters.html.

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

[DonJayamanne]

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]

From @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]

Todo: Add support for docker containers as per #179

[DonJayamanne]

Suggestions for #183

[DonJayamanne]

@vbem, @satyenr , @satyenr, @nffdiogosilva
Hi everyone, I would like to re-visit this to understand the requirements and the constraints.

Here are some of the environments (usages):

• Docker/vagrant containers
• Remove servers (linux, mac, windows)

Requirements:

• Linting (code analysis)
• Code navigation (find references, go to definition, etc)
• Refactoring
• Debugging (done, this works today, but SSH is to be looked at - separate issue)

One possible solution I'm thinking of is:

• Install nodejs on the remote server
• Install a npm package (nodejs module)
• Start a socket server on this target server
• VS Code will communicate with the remote server over a socket connection

This is the easiest solution and quickest to implement.
However, this requires the installation of:

• nodejs on the server
• an npm package

Would this be acceptable?

The only other solution is the following one. However this would take a lot longer to develop and implment:

• install a python package on the server

[DonJayamanne]

From @satyenr on October 4, 2016 9:12

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.

[DonJayamanne]

@satyenr

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.

Finally, an open protocol does exist today:
https://github.com/Microsoft/language-server-protocol

Again, implementing this will be done at a later stage.

• Phase 1: Custom protocol with solution developed in nodejs
• Phase 2: microsoft language server protocol
• Phase 3: Develop this in Python

[DonJayamanne]

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:

volumes:
  - ./django:/usr/app
  - /usr/local/lib/python3.5

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.

[DonJayamanne]

There are two ways to implement this feature:

Option 1: Add dependency on node.js on the remote server

Benefit: Easier to develop
This is the easiest option for me (less python code), more node.js (javascript) code - i'm familiar with this

[DonJayamanne]

There are two ways to implement this feature:

Option 2: Add dependency on node.js on the remote server

Benefit: No dependency on node.js (except some other python libraries that I'll have to write)
Will require more work as I'll need to write everything from scratch using Python (this isn't my language of choice).

[brettcannon]

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]

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]

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!