`python3 -m venv NAME`: virtualenv is not portable

[Marco-Sulla]

BPO	36964
Nosy	@vsajip, @EpicWink, @Marco-Sulla, @cameronhudson8

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2019-05-23.20:52:06.715>
created_at = <Date 2019-05-19.12:07:19.223>
labels = ['3.8', 'type-feature', 'library', 'invalid']
title = '`python3 -m venv NAME`: virtualenv is not portable'
updated_at = <Date 2020-12-02.21:59:40.686>
user = 'https://github.com/Marco-Sulla'

bugs.python.org fields:

activity = <Date 2020-12-02.21:59:40.686>
actor = 'Marco Sulla'
assignee = 'none'
closed = True
closed_date = <Date 2019-05-23.20:52:06.715>
closer = 'brett.cannon'
components = ['Library (Lib)']
creation = <Date 2019-05-19.12:07:19.223>
creator = 'Marco Sulla'
dependencies = []
files = []
hgrepos = []
issue_num = 36964
keywords = []
message_count = 18.0
messages = ['342842', '342891', '342954', '343326', '343519', '344285', '344468', '344523', '344572', '344624', '344626', '344629', '344632', '345004', '345010', '345756', '382334', '382346']
nosy_count = 4.0
nosy_names = ['vinay.sajip', 'Epic_Wink', 'Marco Sulla', 'CameronHudson8']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue36964'
versions = ['Python 3.8']

[Marco-Sulla]

I'm telling about python3 -m venv VIRTUALENV_NAME, not about the virtualenv binary.

Some remarks:

1. VIRTUAL_ENV variable in activate script is the absolute path of the virtualenv folder

2. A symlink to the python3 bin of the machine is created.

This makes the virtualenv difficult to export to another machine. The VIRTUAL_ENV variable must be manually changed.

Furthermore I do not understand why the simlink is created. I suppose that python3 is already on the PATH, so what's the purpose of simlink?

I propose to makes VIRTUAL_ENV eqauls to the parent folder of the directory where activate resides. It makes it possible to move the virtualenv and copy it to another machine with the same OS.

[EpicWink]

Furthermore I do not understand why the simlink is created. I suppose that python3 is already on the PATH, so what's the purpose of simlink?

On machines with multiple Python installs (eg Python 3.6 and Python 3.7, or a distributed Python 3.7 and a user-built Python 3.7), python3 from PATH may refer to the incorrect installed version. Having a symlink to the the Python executable which built the environment (by default; --copies overcomes this) forces an executable.

This python3 symlink still makes it distributable to other machines on the same platform anyway: /usr/bin/python3 should always be available on other distributions with Python installed normally, and Windows copies the Python executable anyway AFAIK.

Across-platform is likely not going to work anyway: it's likely that your virtual environment will contain platform-specific installations of the packages, meaning they won't work on other platforms. If you just want Linux/MacOS portability, check out the Pex project.

I agree with VIRTUAL_ENV being relative however

[Marco-Sulla]

Well, I didn't know --copy. I think I'll use it. :)

What about VIRTUAL_ENV="$(dirname "$(dirname "$(readlink -nf "$0")")")"? In bash and in sh it works.

[brettcannon]

Virtual environments are not designed to be portable. For instance, if you have entry points installed then moving them to another machine would break their shebang lines. And even if you do it on your local machine there's no guarantee something else wasn't structured to be directory-specific.

So thanks for opening the issue, but I'm closing as not a bug.

[Marco-Sulla]

if you have entry points installed then moving them to another
machine would break their shebang lines.

Not if you port it on the same OS using, for example

#!/usr/bin/env python3

And even if you do it on your local machine there's no guarantee
something else wasn't structured to be directory-specific.

You are telling about user code, not the virtualenv itself. If the user doe not write the code in such a way it's portable, it's his fault. But this should not stop people that do it right to try to port the venv if possible.

I think the modification
VIRTUAL_ENV="$(dirname "$(dirname "$(readlink -nf "$0")")")"

is very little and quite robust. Don't know how to do in fish and csh shells, but in bash and sh it works.

[Marco-Sulla]

Well, what about the modification to VIRTUAL_ENV? I think it's little and without harm.

[brettcannon]

Changing VIRTUAL_ENV will break code, so I'm not sure if it's worth changing.

[Marco-Sulla]

Changing VIRTUAL_ENV will break code

VIRTUAL_ENV it's the same if you don't move the venv. Moving it will be an unofficial unsupported bonus, and if you coded bad and it doesn't work, it's your fault.