How to set a remote virtualenv as the python interpreter?

Answered
When I go to Settings -> Project Interpreter -> Python Interpreters, I can either assign a local or remote python interpreter, or a local virtualenv. There doesn't appear to be an option to assign a remote virtualenv. Why is this? Am I missing something? I would prefer to keep my remote projects within their own virtual environments.
14 comments
Comment actions Permalink
Add your remote virtualenv as a remote interpreter and point to a virtualenv's python executable (like this: <Your virtualenv root>/bin/python).
1
Comment actions Permalink
This approach works for me, but with issues: PyCharm can't find imports from within the remote virtualenv.

E.g. remote interpreter –> <virtualenv_root>/bin/python
<virtualenv_root>/lib/python2.7/os.py exists, but when I "import os" I get red squiggly line –> "no module named os".

In contrast, when I use the systemwide remote interpreter (/usr/bin/python) such imports resolve normally and I can view their source.

This is PyCharm 3.4.1.
0
Comment actions Permalink

I know this is an older issue, but I am running into the same challenge with PyCharm version 2017.2.  

I was able to successfully configure my remote virtual environment, however the remote virtual environment does not source the '$WORKON_HOME/bin/activate' file.  I have set a couple of environment variables in the $WORKON_HOME/bin/activate' file.  If I SSH into the remote system, then execute 'workon python3.6' the environment variables are set correctly.  But, when I run a test case in PyCharm using the remote virtual environment as the interpreter, the environment variables are not set.

It seems PyCharm finds all of the virtual environments python packages, but does not find the environment variables.  Unless I am missing something that is.  Can you please advise on how to correct this issue?

1
Comment actions Permalink

Does anyone have a solution to this?  The remote function has the potential to be incredibly useful, but complete support for remote environments is critical.

2
Comment actions Permalink

That feature would be great, sadly it still doesn't exist :(

0
Comment actions Permalink

Is this solved in PyCharm-2018? 

0
Comment actions Permalink

Hi Thomas, there're multiple problems described in this thread, which one do you refer to? In general case everything should work - you can add a virtual environment on the remote machine as an interpreter in PyCharm. Meanwhile, PyCharm does not source activate, but it should not bother you until you edited the activate script by hand. It is also impossible to create a venv on the remote machine with PyCharms' UI.

0
Comment actions Permalink

 It will indeed bother you if you execute `python` in your scripts (e.g. in tests). You can set your interpreter path to be the virtualenv's one, but without "getting into virtualenv" - sourcing activate - `python` won't refer to your virtualenv's python and instead to your system's one.

0
Comment actions Permalink

It seems that the same issues all apply for the usage of `pipenv` on a remote machine.

The main problem is, that PyCharm does somehow not recognize which packages are installed and therefore has no auto complete. This makes me want to switch to Visual Studio Code.

0
Comment actions Permalink

Could you please create a ticket in our bug tracker and attach a screenshot of the interpreter settings in PyCharm? This really should work right away by selecting a correct Python executable so it's either a misconfiguration or an unknown bug on PyCharms' side.

0
Comment actions Permalink

Would it be a solution to add

source venv/bin/activate

to the ~/.bashrc file of the user used to SSH to the remote server?

0
Comment actions Permalink

@Francesco Trotta

There shouldn't be a need for that - PyCharm 2019.1.3 support remote virtualenv environments, if you create a remote interpreter and point it to venv/bin/python

0
Comment actions Permalink

@Andrey Resler

Thank you for your reply.

I confirm that, adding a new "SSH interpreter" and make it point to the Python of a venv in the remote host, solves the issue. No activation is needed.

0

Please sign in to leave a comment.