[Distutils] [final version?] PEP 513 - A Platform Tag for Portable Linux Built Distributions

[Donald Stufft]

> On Feb 16, 2016, at 1:33 PM, Barry Warsaw <barry at python.org> wrote:
> 
> I don't, but I hope that should not be a problem these days, with modern pip
> on modern Debian/Ubuntu systems.  We prevent pip from installing in system
> locations in various ways, including making --user the default.
> 
> I don't think we're doing anything that isn't at least within the pip
> roadmap.  E.g. --user will probably someday be the default in stock pip, but
> because of reasons it hasn't happened yet.
> 
> IIRC, Donald was also talking about better ways to detect system owned files,
> so pip would also refuse to overwrite them.

Replying to Barry, but also to generally the whole sub-thread!

First off, there is very little chance pip ever removes the ability to install
directly into a system Python. So any proposal to remove that functionality is
unlikely to ever be accepted without an incredibly compelling reason.

As far as some sort of "tainting" goes, that's not really related to this PEP
at all, and as of pip 8.0 we already include information when we install a file
that says that this particular item was installed by pip. That can be accessed
using pkg_resources::

    >>> pkg_resources.get_distribution("twine").get_metadata("INSTALLER").strip()
    'pip'

As far as I know, nothing actually uses that metadata right now, but that
should be plenty for some sort of tooling to be written that can tell a distro
if there are any non-distro provided packages in an enviornment using something
like:

    >>> for d in pkg_resources.working_set:
    ...     if d.has_metadata("INSTALLER"):
    ...         print("{}: {}".format(d.project_name, d.get_metadata("INSTALLER").strip()))
    ...
    certifi: pip
    packaging: pip
    pkginfo: pip
    pyparsing: pip
    pytz: pip
    requests: pip
    requests-toolbelt: pip
    setuptools: pip
    twine: pip
    virtualenv: pip
    wheel: pip

Anyways, where I think [1] we're heading:

* When we don't actually have permission to install into site-packages, then
  default to --user. This will stop leading people towards using sudo because
  they typed ``pip install foo`` as a user and got a permissions error, the
  logical way to solve that being ``sudo !!``.

* Standardize the patches Debian has which splits up a vendor location from the
  site location, giving distros a different place to install things than where
  pip will install by default.

* Provide a mechanism that will enable vendors to say that some particular
  install package is system owned, and then have pip refuse to modify those
  files without some sort of --yes-i-know-what-im-doing flag.


At this time, I don't personally have any plans to add anything like pipsi but
I'm not strictly opposed to it either. The largest problem with that is we
don't have a good way of knowing, when someone does ``pip install foobar`` if
they want to install foobar because it's an isolated bin they want to run, or
if it's something they want to be able to import in their current environment.


[1] These are my opinions, and none of them are set in stone.

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160217/4c89e36e/attachment.sig>