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

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