2009/7/8 P.J. Eby <p...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
