I recently switched back to Debian testing and since last June, testing is Debian 13 (codename Trixie). As I was installing a bunch of Python packages, I got the following error:
As it turned out, Debian has adopted PEP 668 a few months ago. In a nutshell, the PEP 668 is motivated by the fact that most distros ship Python and install Python packages via their own package manager (e.g.
apt on Debian) and that there are potential conflicts between these packages and the ones installed via
pip. For instance, the following command line shows that I have almost 200 python packages installed via
apt (as mentioned above they start via
So if I want to install a new package to do some analysis,
apt may encounter situation where a package I need will conflict with one installed, but the one installed is installed for at least one software program I used… so better not do anything wrong with those packages. Debian has been using for quite some time a mechanism to prevent this from happening, but if you read the PEP 668 closely, you will the paragraph below explaining one way to bypass this safety guard:
(We have seen user reports of externally-installed packages being deleted on Debian or a derivative. We suspect this is because the user has previously run sudo pip install –upgrade pip and therefore now has a version of /usr/bin/pip without the Debian patch; standardizing this behavior in upstream package installers would address this problem.)
I am pretty sure I did that many times, because I was not able to install the package I needed, I was lucky that nothing was broken…
Anyway, the solution proposes is a standardized mechanism to warn the user that python packages are managed (precisely the message above) and to suggest to use a virtual environment such as
venv. And so I installed a virtual environment (see this thread on StackOverflow
). Note that using Conda is also a suitable option. To easily trigger the virtual environment I created an alias venc, which I call when I launch Python (I use ipython).