[Python-Dev] PEP 376 - Open questions

[Paul Moore]

2009/7/8 P.J. Eby <pje at telecommunity.com>:
> At 03:57 PM 7/8/2009 +0100, Paul Moore wrote:
>>
>> Who's going to use the APIs based around the RECORD file? Anyone?
>
> The distutils uninstall facility, for starters.  easy_install and pip also
> will, eventually.

Is pip getting this via setuptools, or will it be independently
changing its code? (Who's the pip contact who could confirm this
directly?)

> In all three cases, the use will be in order to avoid overwriting files
> belonging to a system package manager, and in order to uninstall/upgrade
> their own files.

To uninstall/upgrade their own files counts as "an installer-specific
detail" in the sense that Eric stated it.

To avoid overwriting files belonging to a system package manager: That
sounds like we're looking at a use case where people use a mixture of
tools to install packages into the system Python. Personally, I never
do this (I use bdist_wininst exclusively). The cases I can imagine
are:

- no OS-specific package available, and the user can't build his own,
so he uses setup.py install.
- user using easy_install as well as the OS package

In case (1), I'd imagine the user is careful enough (given that he's
doing everything manually) to avoid installing something that's
already present.
Case (2) is setuptools-related (see below for setuptools-related comments).

> (I can't personally commit that pip will need this; but it's currently the
> only installer besides the distutils that installs things in this format,
> and would therefore need this to prevent overwriting things.)

Not the only one - MAL mentioned his (internal use?) packaging process.

> Setuptools will also need to generate RECORD, INSTALLER, and PREFIXES
> appropriately for both development and actual installations.

If no-one else is using them, that's an internal setuptools detail
again. Or it's for interoperability between setuptools and distutils
(and other packagers don't benefit unless they are using PEP 376
APIs).

>> Seriously - who is actually going to USE any of the APIs being
>> proposed in PEP 376? If no-one's interested, we should stop right now.
>> Do any of the people from the summit read this list? If not, can
>> anyone contact them and get some feedback?
>
> Package management people aren't likely to be doing anything with this stuff
> directly; if they need a list of installed files they're probably using
> --root or --record at package build time, not needing to sniff stuff and
> installation time, and they already have installation facilities.  Their
> only real need in relation to this will be to set an option to generate an
> INSTALLER file that says you can't uninstall their packages manually,
> thereby preventing the package from being uninstalled by the distutils
> utility, or any other well-behaved PEP 376-based package management tool.

So if I follow this, there's a use for this in making sure the new
distutils uninstall option doesn't break something it shouldn't, but
as the uninstall uses RECORD, it won't be (accidentally) usable on
distributions that didn't follow PEP 376 and create a RECORD file.

There's also a use for this in terms of setuptools/easy_install
interoperability.

I'm now going to take of my "PEP supporter" hat, and put on my "End
user" hat. Please understand that the following is *not* unbiased,
whereas the rest of what I've said *is* intended to be reasonably
impartial.

If the only driver for this PEP is setuptools, then I'm -1 on it.

Unless someone working on a packaging tool *other* than setuptools (or
setuptools-derived projects) speaks up and says "I have code of my own
which uses distutils, and I would benefit as follows from PEP 376 and
I will be changing my code to conform to PEP 376" I think the PEP
should be rejected, and the energy put into some other PEP which will
benefit the wider (non-setuptools) community.

OK, end of the opinion bit. I'll go back to trying to keep things
impartial in future mails.

Paul.

PS Note - I like the idea of the PEP in theory. It's the practical
benefits that I'm trying to establish.