[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Amend Debian Python Proposal to Include More Python Metadata?



> On Jan 22, 2016, at 11:18 AM, Piotr Ożarowski <piotr@debian.org> wrote:
> 
> let's make a deal. If you will make sure pip doesn't touch system files
> (and others will not crucify me for this) - I will make sure pybuild
> uses above line (if setuptools is not detected in setup.py but is listed
> in Build-Depends).

Regardless of what happens in this thread, pip is going to stop mucking around
in files that are owned by some other tool without some sort of opt-in/--force
style flag *and* we're going to be restructuring things to try and guide people
away from using pip outside of a virtual environment or through the user of
--user as well.

The main reason why that hasn't happened yet isn't because I'm holding those
things hostage, it's because I'm one person and my time is spread amongst
several really important tools and I have to prioritize things in accordance to
how bad it's on fire. In addition, pip is a cross platform program and we have
to ensure that whatever we do works in a cross platform manner. You mentioned
/usr/local/.../site-packages/ before, but plenty of systems don't have a
/usr/local/.../site-packages/ that their Python respects because that is a
Debian specific patch, so if we refused to install to /usr/.../site-packages/
we'd break installing at the system level on all platforms but Debian derived
ones.

What we need is a cross platform way to determine if a particular installed
Python package is "owned" by the system or if it's something we're allowed to
modify. That's going to require some effort to work out the exact best way,
but in my head the way forward on that is to use the metadata directory (the
one I'm asking y'all to start using) and add an additional piece of metadata
inside of it that just says "Hey, This is a system install" that we can inspect
and then take additional logic (like refusing to touch it without a --force)
based on that. The change I'm asking for here helps make that possible (among
other things).

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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail


Reply to: