venv activate script would be good to show failure.

[br-kim]

BPO	44286
Nosy	@vsajip, @br-kim

^{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 2021-06-04.13:43:29.519>
created_at = <Date 2021-06-02.14:03:06.187>
labels = ['3.7', 'invalid', 'type-feature', 'library']
title = 'venv activate script would be good to show failure.'
updated_at = <Date 2021-06-04.13:43:29.518>
user = 'https://github.com/br-kim'

bugs.python.org fields:

activity = <Date 2021-06-04.13:43:29.518>
actor = 'idle947'
assignee = 'none'
closed = True
closed_date = <Date 2021-06-04.13:43:29.519>
closer = 'idle947'
components = ['Library (Lib)']
creation = <Date 2021-06-02.14:03:06.187>
creator = 'idle947'
dependencies = []
files = []
hgrepos = []
issue_num = 44286
keywords = []
message_count = 5.0
messages = ['394909', '394997', '395002', '395074', '395083']
nosy_count = 2.0
nosy_names = ['vinay.sajip', 'idle947']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue44286'
versions = ['Python 3.7']

[br-kim]

I changed the path of the project using venv, so it didn't work properly.

I thought it worked successfully because there was a (venv) on the terminal line.

However, the __VENV_DIR__ in the

set "VIRTUAL_ENV=VENV_DIR"

in the activate script did not work properly because it was the PATH before the replacement.

How about adding a procedure to verify the __VENV_DIR__ is a valid PATH to the Activate Script?

[vsajip]

venvs aren't meant to be portable (i.e. renaming the directory or moving to a new location). Scripts installed into a venv have absolute paths pointing to the location when the venv was created.

venvs should be treated as throwaway resources that can be readily recreated - so if you need a venv in a new location, just create it there and install the desired packages again.

[br-kim]

Thank you for your explanation of venv.

I understand that venv is not portable.

But I was confused because the venv was written on the left side of the terminal line and it looked like it was working.

Therefore, if venv does not work, such as if __venv_dir__ is invalid path, i thought any warning message or exception handling was necessary. Or (venv) doesn't show up.

[vsajip]

i thought any warning message or exception handling was necessary. Or (venv) doesn't show up.

No, because these are just scripts created by venv and placed in the venv's directory tree. If you then move the files to a different location, they aren't engineered to notice, and so will not behave as you expect.

As venv's aren't meant to be moved, there's no particular reason to engineer for that possibility.

OK to close this issue as "not a bug"?

[br-kim]

Okay. Thank you for the detailed explanation.

[carlwr]

I suggest re-opening this issue.

These problems seem common and elusive[1] and the fix is seemingly easy to implement.

Motivation

If an unknowing user...

1. moves or renames the project directory, and then
2. activates the venv

...then, the current behaviour is:

• silently, the venv won't be activated
• no error message or hint about this will be given
• to the contrary, the user will believe everything is OK since the prompt changes
• there will be all kinds of strange and hard-to-troubleshoot behaviour, e.g. the wrong (system) interpreter being used and installing packages will install them globally

(this happened for me; I came here after hours of trouble-shooting)

The desired behaviour would be:

• print an error message
• don't activate the venv

@vsajip:

venvs aren't meant to be portable

Apparently not, which is fine. This would be an argument for this easy fix.

Renaming or moving a source/project dir is common, and some users will expect it to be possible, believing paths are relative, as is most common for tools working on source dirs. If in doubt, it's not unlikely for a user to simply try, and then believe all is well since the venv seemingly activates successfully (the prompt changes). Often, no problems show up at first; instead subtle problems appear later, stemming from unknowingly installing to and using global packages.

Fix

It seems this fix would be easy to implement.

https://github.com/python/cpython/blob/main/Lib/venv/scripts/common/activate:

now:

[...]
# unset irrelevant variables
deactivate nondestructive

VIRTUAL_ENV="__VENV_DIR__"
export VIRTUAL_ENV
[...]

change to something like:

[...]
# unset irrelevant variables
deactivate nondestructive

if [ ! -d "$__VENV_DIR__" ]; then
    echo "Error: virtual environment directory $__VENV_DIR__ doesn't exist." >&2
else
  VIRTUAL_ENV="__VENV_DIR__"
  export VIRTUAL_ENV
  [...] # (rest of file in this else-clause)
fi

(The absolute path in __VENV_DIR__ not existing is not an absolute guarantee that the project dir wasn't moved/renamed, but would probably catch 95% of these cases. Importantly, there won't be any false positives: if no dir exists for the path in __VENV_DIR__, there's no chance that activating this path as a venv is successful.)

[1]: seemingly common and frustrating problem

Some examples of reports of this specific problem below. Most mention being misled by lack of error message and by believing the prompt changing indicated successful activation. There's sometimes a high degree of frustration, and a simple error message seemingly would have helped most of them. Several at first had no indication that the experienced problems were caused by a move/rename of the source dir.

• https://salvicode.com/post/do-not-move-your-python-project-folder/
• https://stackoverflow.com/questions/41524320/virtualenv-uses-wrong-python-even-though-it-is-first-in-path
• https://stackoverflow.com/questions/59302178/python-virtual-environment-does-not-default-python-packages
• https://stackoverflow.com/questions/65390129/venv-activate-doesnt-not-change-my-python-path
• https://stackoverflow.com/questions/63932002/unable-to-clone-python-venv-to-another-pc
• https://stackoverflow.com/questions/49567494/activating-python-virtual-environment-does-not-switch-to-local-versions-of-pip-a
• https://stackoverflow.com/questions/41608432/virtual-environment-is-not-activating-after-re-installation-of-virtualenv

(there are many more)

Some SO question on moving source dirs with venv, and on whether this is possible/problems that follow from it:

• https://stackoverflow.com/questions/32407365/can-i-move-a-virtualenv (130 upvotes)
• https://stackoverflow.com/questions/6628476/renaming-a-virtualenv-folder-without-breaking-it (170 upvotes).

Notes

For reference, here are some requests to make the venv paths relative, along with explanations for why that would be a lot of work/not viable:

• pyvenv: venvs cannot be moved because activate scripts hard-code paths #70020
• Support for relative home path in pyvenv.cfg #83650
• Make VENV_DIR relative to Script directory #71335

[vsajip]

I added a warning about non-portability of venvs to the documentation. I can try and review any PRs with tests that are related to error checking in the activation scripts.

[carlwr]

Doc update: that's great.

Activation script error check:

I'm not the right person to make a PR unfortunately.

I still suggest re-opening this issue so an error check is addd eventually. Not having one has evidently caused a lot of users a lot of trouble and the fix is straight-forward.