I thought the major point of supporting the creation of "native" binary packages was so that installation and dependencoes could be handled however the local architecure handles it. Doing "python setup.py install" is no different that "./configure && make install". Neither one is going to look to see if anything's already there. "python setup.py bdist_whatever", however will create a nice, neat little package. With the full implementation of PEP241 standards, (esp. standard names and versions) the package manager will know if a package is already installed, and _it_ will do appropriate warnings, allow for "forcing", deal with multiple version installs, ... , all the things that package managers do. If all this stuff is packed into distutils, then administrators will have to look in multiple places to figure out what is installed on which machine. I see distutils as a distribution tool, not an administration tool. Like it or not, different platforms come with different administration tools, and no matter how good open general-purpose replacements are, they're a pain to keep in sync with the one the vendor uses. mwa On Fri, 8 Jun 2001, Mats Wichmann wrote:
Prior discussion has roughly been:
My gripe: the fact that a package is already installed is not detected with a warning.
Thomas Heller: This should probably wait until there is a distutils registry of installed modules.
Me: Is this in the works?
Thomas: No, I'm not aware of any activity.
He goes on to say folks (well, AMK) know it's needed, and probably requires a PEP.
Should we get that ball rolling? In the most general terms, it appears that PEP 241 formally, plus just "how distutils works", describes one of the software collection types we're interested in: the distribution (although PEP 241 itself appears to describe only one component of the distribution, the metadata, or what other terminology calls a "Software Definition File").
The other type we need, to implement things like removal, show installed packages, detection of previous install of same or different version, track dependencies (gack...no... not RPM!!!), etc., is an "installed software" collection.
I'd propose that's an appropriate subject for a PEP. I don't have any idea how much or how little of this is considered "necessary" (as opposed to "might be nice").
(I can volunteer to carry the ball if necessary, but I'm sure I'm nowhere near the best qualified person).
Mats
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
-- Mark W. Alexander slash@dotnetslash.net