Bug? Changing Default Pip Install Location broke venv isolation

Python Help
1

How do I Change Default Pip Install
Location and keep venv working fine?

I change the default Pip Install Location,
in a Linux system, following these two guides:

It works, except now venv is always targeting global location,
so I no longer have venv isolation.

To Change Default Pip Install Location,
I did two thing:

  1. Edit pip.conf 
$ vim $HOME/.config/pip/pip.conf
[global]
target=/opt/py3.10/packages
  1. Add two environment variables to ~/.profile
$ vim ~/.profile
export PYTHONPATH=/opt/py3.10/packages
export PIP_TARGET=/opt/py3.10/packages

Testing venv…

$ python3 -m venv ve

$ source ve/bin/activate

(ve)$ pip list
Package                 Version
----------------------- ---------------
:
(long system package list)
:

(ve)$ python -m pip list
Package    Version
---------- -------
pip        22.2.2
setuptools 65.3.0
wheel      0.37.1

(ve)$ python -m pip install h11
Collecting h11
  Using cached h11-0.13.0-py3-none-any.whl (58 kB)
Installing collected packages: h11
Successfully installed h11-0.13.0

(ve)$ python -m pip list
Package    Version
---------- -------
h11        0.13.0
pip        22.2.2
setuptools 65.3.0
wheel      0.37.1

(ve)$ python -m pip uninstall h11
Found existing installation: h11 0.13.0
Not uninstalling h11 at /opt/py3.10/packages, outside environment [.../ve]
Can't uninstall 'h11'. No files were found to uninstall.

How do I change Default Pip Install
Location and keep venv working fine?

Regards

2

I’m not too sure if this will help…

If not, I’m sure that someone with way better knowledge than I, will follow up on this and you’ll get the information that you need.

Sorry that it’s simply a link, rather than from my own experience, which I can’t offer on this topic.

2 Likes
3

When you install a module or package using pip in the following manner:
pip install --target=<some_python_library_location> <package>
you would expect the package to be installed at the target. If you check-out the documentation, it tells you that that is what happens. It only saves you the typing.

I’m struggling to see why you would want that. You already have separation between the different projects (that is what venv is for) and the separation between different Python versions (comes out of the box). I see only use for the configuration option if you have a constrained system with only 1 Python and you still want to separate the distribution installed library from your own installed packages. It than saves you from the (small) bother of maintaining a virtual environment. Can you elaborate?

2 Likes
4

I’m just managing the space on my drives.

I have fixed (temporarily) reverting
what I did when I’m going to use a venv.

  1. I have removed permanently the
    global target in ~/.config/pip/pip.conf
  1. I am removing dynamically the two
    environment variables defined in
    my ~/.profile, using some
    alias functions in my ~/.aliases
$ vim ~/.aliases
vact(){
  unset PIP_TARGET;
  unset PYTHONPATH;
  source $1/bin/activate;
}
venv(){
  unset PIP_TARGET;
  unset PYTHONPATH;
  python3 -m venv $1;
  source $1/bin/activate;
}
deact(){ deactivate;
  local pydir=/opt/py3.10/packages;
  export PYTHONPATH=$pydir;
  export PIP_TARGET=$pydir;
}

Now I can make a new venv and
activate immediately with:
venv ve
or activate an existent venv with:
vact ve
and deactivate with:
deact

5

Well, at least I now understand :grinning:.

I do not install any wheel into the distribution managed environments, so I do not need a workaround to keep these separate from the software supplied by the distribution. Cannot help you there, sorry. Maybe do everything in a venv, instead of (sometimes) still using the distribution installed software?

Your solution will work, but you should never forget to deactivate, otherwise things go wrong. I would prefer a solution which tells pip what to do (e.g. based on a small script in your home directory).