[Bug]: `pip install` no longer works in 1.6.0 venvs

[keith]

What happened?

% which pip3
.../_main/bazel-out/k8-dbg/bin/utils/packaging/wheel/fix_wheel/fix_wheel.venv.runfiles/rules_python++python+python_3_12_x86_64-unknown-linux-gnu/bin/pip3
% pip3 install requests
Defaulting to user installation because normal site-packages is not writeable

Version

Development (host) and target OS/architectures:

Output of bazel --version:

Version of the Aspect rules, or other relevant rules from your
WORKSPACE or MODULE.bazel file: 1.6.0, didn't bisect was previously on 1.3.2

Language(s) and/or frameworks involved:

How to reproduce

Any other information?

No response

[keith]

I debugged this a bit more. The way this worked before is a user would first install pip, since it wasn't previously installed in the venvs with:

curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py
python3 get-pip.py

notably python3 -m ensurepip has different behavior

then after this installation pip3 install whatever would work as expected.

Now that it seems like the venv is a symlink into bazel-out, it is no longer writable so this no longer works. Manually changing the permissions also seems like a bad idea

[arrdem]

It's a regression yes but not really a bug. venv_link gives you a link to the venv defined by your Bazel target and as will be used by the binary hermetically. That venv isn't supposed to be mutable or useable in the way you're describing here.

I think you want something closer to the previous behavior of building an entirely Bazel-external venv tree.

[keith]

yea i think there's a lot of value in that workflow in order to test other packages. our developers often install developer-only tools that we might not want to include as a dep of all python packages, or test new / old versions of packages to ensure compatibility