At 05:22 PM 7/8/2009 +0100, Paul Moore wrote:
>2009/7/8 P.J. Eby <pje(a)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
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
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.)