[Distutils] PEP 439 and default install locations (was Re: distil 0.1.1 released) (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Sat May 4 03:47:27 CEST 2013

On 4 May 2013 09:03, "Carl Meyer" <carl at oddbird.net> wrote:

Hi Nick On 05/03/2013 12:14 PM, Nick Coghlan wrote: > I would also be relatively happy for pip to refuse the temptation to > guess if run globally and require an explicit --user or --system > whenever it is run outside a virtual environment. However, I think it's > better to make the typical "pip install whatever" work for most > unprivileged users without requiring elevated privileges. > > I agree the proposed exception for root doesn't make sense so I withdraw > that idea, even though installing things into root's home directory is a > little strange. > > As far as Debian's dist-packages setup goes, that's their workaround for > this misfeature of the current Python packaging ecosystem. IMO requiring either --user or --system is bad UI (we should have a sane default). Defaulting to --user is tempting, but also a bad idea, both because of the massive adjustment that it would require from existing users, and because it does the wrong thing in many cases where there are multiple Pythons compiled on the system. I think the best solution to this problem is quite easily implemented and non-intrusive: an improved error message when pip finds that it lacks permission to install to site-packages. This error message could recommend --user and/or virtualenv, could warn quite strongly against installing to this location unless you really know what you are doing, etc.

That sounds eminently reasonable.

Also, I think that for the specific situation of a Linux distribution's "system Python" (which, as Donald has pointed out, is only one mode of Python installation out of many), Debian's solution is better than just a workaround, it is conceptually more or less the Right Thing: separate distro-managed Python code from user-managed Python code, without preventing independent installation of Python-installation-wide code by the user.

(Though some aspects of the implementation of Debian's solution are sub-optimal and have required ugly workarounds in pip. It would be better if multiple site-packages were a first-class concept in Python's own site.py so Debian's solution could be implemented via configuration rather than patches.)

Agreed, blessing something like Debian's solution sounds like a better idea than changing pip's default installation location. To provide that blessing, I think PEP 439 should be expanded to explicitly cover this aspect (there's another subtlety, in that it may be desirable for distro packages to be available when running with -S - I'm not sure how Debian currently handle that).

Essentially, my goal is to have a clearly defined, consistent, cross-distro-and-platform shadowing behaviour for cases where you install a Python software distribution from a system package manager and through pip. The current situation, where the system tools and the Python specific tools tread on each other's toes at the filesystem layer (unless you change the default Python path, as Debian does) isn't appropriate for something we are going to ship as part of the standard Python toolkit.

(Coincidentally, this may lead to my CPython bootstrapping changes becoming packaging related!)

Cheers, Nick.

Carl

Distutils-SIG maillist - Distutils-SIG at python.org http://mail.python.org/mailman/listinfo/distutils-sig -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130504/35e81845/attachment.html>

More information about the Distutils-SIG mailing list