[Python-Dev] PEP 376 - Open questions

[P.J. Eby]

At 05:22 PM 7/8/2009 +0100, Paul Moore wrote:
>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?)

It would likely be changing its code directly, with respect to 
supporting overwrite-avoidance and uninstall-before-upgrade 
scenarios.  (Generation support would likely come from setuptools, 
dependent on who implemented first.)  Ian Bicking is pip's author.


>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.

Obviously, you've never tried doing this yourself.  ;-)

My guess would actually be that in Unixy environments these days, 
people either use virtualenv or buildouts to manage such 
things.  Buildout handles uninstall-before-update (for eggs, anyway, 
I'm not sure about other things) and virtualenv makes it easy to 
create throwaway Python installs.


>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.

That's an interesting point.  But for non-distutils tools, it'd be 
nice to be able to find out whether another package manager is 
administering some particular file.  For that matter, the distutils 
themselves should (ultimately) support uninstall-before-upgrade and 
avoid overwriting another package manager's files.


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

If it were being driven by setuptools, I'd have just implemented it 
myself and presented it as a fait accompli.  I can't speak to Tarek's 
motives, but I assume that, as stated in the PEP, the primary driver 
is supporting the distutils being able to uninstall things, and 
secondarily to allow other tools to be built on top of the API.


>a packaging tool *other* than setuptools (or setuptools-derived projects)

Is there really such a thing?  ;-)

AFAIK, every published tool for managing Python projects is either 
distutils-based or setuptools-based.  (Things like scons and pymake 
and various other project build tools don't seem to fall under 
"packaging tool" in this sense.)