On 24/02/2021 08.03, Michał Górny wrote: > On Tue, 2021-02-23 at 19:45 -0500, Random832 wrote: >> I was reading a discussion thread >> <https://gist.github.com/tiran/2dec9e03c6f901814f6d1e8dad09528e> about >> various issues with the Debian packaged version of Python, and the following >> statement stood out for me as shocking: >> >> Christian Heimes wrote: >>> Core dev and PyPA has spent a lot of effort in promoting venv because we >>> don't want users to break their operating system with sudo pip install. >> >> I don't think sudo pip install should break the operating system. And I >> think if it does, that problem should be solved rather than merely advising >> users against using it. And why is it, anyway, that distributions whose >> package managers can't coexist with pip-installed packages don't ever seem >> to get the same amount of flak for "damaging python's brand" as Debian is >> getting from some of the people in the discussion thread? Why is it that >> this community is resigned to recommending a workaround when distributions >> decide the site-packages directory belongs to their package manager rather >> than pip, instead of bringing the same amount of fiery condemnation of that >> practice as we apparently have for *checks notes* splitting parts of the >> stdlib into optional packages? Why demand that pip be present if we're not >> going to demand that it works properly? >> >> I think that installing packages into the actual python installation, both >> via distribution packaging tools and pip [and using both simultaneously - >> the Debian model of separated dist-packages and site-packages folders seems >> like a reasonable solution to this problem] can and should be a supported >> paradigm, and that virtual environments [or more extreme measures such as >> shipping an entire python installation as part of an application's >> deployment] should ideally be reserved for the rare corner cases where that >> doesn't work for some reason. > > The problem is a little deeper and the Debian solution doesn't really > solve all of it. > > Yes, pip installing into the same directory as the package manager > is a problem. It's a problem to the point that I'm patching pip > in Gentoo to explicitly block that. We've gotten far too many bug > reports about people's systems suddenly being horribly broken after they > used pip. > > While using two directories can prevent pip from directly overwriting > system packages, you still can't expect two independent package managers > to work simultaneously unless they can communicate with each other to > prevent conflicts. If pip installs a different version of the same > package as the package manager, which one is supposed to be used? > Whichever choice you make, you'll bound to eventually break dependency > graph of some package.
Thanks Michał, you have explained the situation well. Most Linux distros have two separate directories for distro packages and "sudo pip install" packages. This is a great thing! Separate directories don't prevent clashes and system breakage. But they provide an easy way to *recover* from a broken system. The package manager of several Linux distributions is written in Python. If your system Python is broken, your package manager is likely busted as well. The split directories allow ysers to fix their system with a single command like "sudo rm -rf /usr/local/lib/python*" (paths may vary). The issue is: Split distro/pip directories are not baked into Python or pip. Distros have their own set of downstream patches that modify the behavior of Python. Some of the patches have caused issues in the past. I would like to see this feature implemented in Python's core, so distro packages have to do less patching and upstream pip can test against it. Christian PS: I wrote PEP 370 for "install --user" 13 years ago before we had virtual envs. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ZYXP5FARQIYQQTW46UFWVAXQRTFNFRFT/ Code of Conduct: http://python.org/psf/codeofconduct/