0

I have two computers (running Ubuntu) that have access to one server. The shared home directory of the two computers is on the server.

On computer (A) python 3.5 is installed, on computer (B) python 3.7 is installed. I created a virtualenv from computer (B) on the shared home directory (using python 3.7).

Now although it is possible to activate that virtualenv from computer (A) it does not use the "virtualenv-python 3.7" but the system's python 3.5. So technically the virtualenv is activated but effectively it is not.

Note that the VIRTUAL_ENV path is set correctly.

I thought that virtualenv-folder is a fully enclosed environment, not even needing any python installed on the system. So why is it not working?

RolleRugu
  • 233
  • 2
  • 11
  • Use `pipenv` instead: https://stackoverflow.com/questions/41573587/what-is-the-difference-between-venv-pyvenv-pyenv-virtualenv-virtualenvwrappe – Waket Zheng May 14 '19 at 08:15
  • Python virtualenvs are not portable. You have to recreate it on the second host. – phd May 14 '19 at 11:56

2 Answers2

1

The short answer is because on both computers A and B, the path to your python is likely just an alias. You can verify this by following the path on computer B and using the OS's GUI you can see it is a symlink to the actual python installation sitting somewhere else on your machine (probably usr/bin/). For example, on one machine where multiple installations of Python is found, I see that my virtual environment (.virtualenvs/revconnecion/include/python3.6) is an alias to the original /anaconda3/include/python3.6.

enter image description here

Solution:

You can create your virtual environment by specifying the python version itself when creating your environment:

python3.7 -m venv sharedvenv

or:

virtualenv -p python3.7

You can also manually change the symlinks / alias but the above method works better. Using the specific version of Python itself to create the virtual environment leaves no ambiguity and explicit is better than implicit.

Run which python on both Computer A and B to verify that it's pointing to the right version of Python.

onlyphantom
  • 8,606
  • 4
  • 44
  • 58
1

A virtualenv doesn't have a full Python installation. Instead, it links to an installation present on the system (FYI that link is in <env>/lib/orig-prefix.txt). The env's directory tree has some stubs and special logic but it uses the bulk from that installation.

So if you run activate on a system that doesn't have the same Python at the same path as the one virtualenv was created for, that script won't work correctly. It might happen to hook to something else present at the same path but this is not a supported scenario so all bets are off.

If you need a "fully enclosed environment", you may want to take a look at pyenv which does exactly that -- installs a full Python under your home dir. (Or you can just install Python from source to somewhere under your home dir -- but pyenv makes it easy to switch to that installation and back.)

ivan_pozdeev
  • 33,874
  • 19
  • 107
  • 152