Skip to content

RFE: Support Remote Interpreter #79

Closed

Description

From Satyen Rai (@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

Activity

  1. DonJayamanne commented on Nov 13, 2017

    @DonJayamanne
    Author

    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.

  2. DonJayamanne commented on Nov 13, 2017

    @DonJayamanne
    Author

    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.

  3. DonJayamanne commented on Nov 13, 2017

    @DonJayamanne
    Author

    Todo: Add support for docker containers as per #179

  4. DonJayamanne commented on Nov 13, 2017

    @DonJayamanne
    Author

    Suggestions for #183

  5. DonJayamanne commented on Nov 13, 2017

    @DonJayamanne
    Author

    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):

    • 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
  6. DonJayamanne commented on Nov 13, 2017

    @DonJayamanne
    Author

    From Satyen Rai (@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.

  7. DonJayamanne commented on Nov 13, 2017

    @DonJayamanne
    Author

    Satyen Rai (@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
  8. DonJayamanne commented on Nov 13, 2017

    @DonJayamanne
    Author
  9. DonJayamanne commented on Nov 13, 2017

    @DonJayamanne
    Author
  10. DonJayamanne commented on Nov 13, 2017

    @DonJayamanne
    Author
  11. DonJayamanne commented on Nov 13, 2017

    @DonJayamanne
    Author

    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.

  12. 115 remaining items

  13. clumsykun commented on Sep 21, 2018

    @clumsykun
  14. nffdiogosilva commented on Sep 24, 2018

    @nffdiogosilva
  15. woile commented on Sep 24, 2018

    @woile
  16. KyeRussell commented on Sep 24, 2018

    @KyeRussell
  17. brettcannon commented on Sep 24, 2018

    @brettcannon
    Member

    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.

  18. locked and limited conversation to collaborators on Sep 24, 2018
  19. qubitron commented on May 2, 2019

    @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.

  20. ghost removed on May 2, 2019
  21. unlocked this conversation on May 2, 2019
  22. satyenr commented on May 3, 2019

    @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!

  23. locked as resolved and limited conversation to collaborators on May 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    feature-requestRequest for new features or functionality

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions