It seems time to bite the bullet and actually begin designing and implementing a database of installed packages. As a strawman to get a focused discussion started, here's a draft of a PEP, with lots of XXX's in it. Followups to the Distutils SIG, please.
it's definitely off to a decent start, i'll throw out some "things to consider"... if a user changes the install prefix and installs the package somewhere "off the path", does the package manager keep track of it? i'm guessing it should only handle packages inside the python treee? it will be hard to add an automatic "download link" for updating packages. what if a package has increased multiple versions since the package was installed? i think this falls into the realm of the nebulous online package library. the good news about going with a central online repository is that you can automatically get new packages, not just update ones you already have. how to handle the python standard library? is there just a single entry for the entire library? does it not matter since the user can just query the python version and get a good idea of what is available? i'm kind of thinking of the "optional" standard runtime libraries. then again, it's easy enough to see if they exist by catching any Import exceptions, and i don't think this sort of thing has been a problem to anyone in the past. no need to kill ourselves handling something that hasn't bothered anyone before. :] i do like the database of installed files. i see it can already be created by distutils with some options, it should mean 'uninstall' tools are pretty much automatic. we'll need some information in the distutils setup.py to define what the dependencies for a package really are. how should this be layed out? package names with a minimum version? what about binary packages. most windows users don't have a compilers, and will need prebuilt extension modules for their system. again, i believe this falls more into the roll of having an online package repository, but it would be worth mentioning in this pep? for the love of all things good, can we please make a recommendation in our PEP that the windows installation location be something other than "C:\PYTHON21"? something like "C:\PYTHON21\SITE-PACKAGES" would be a big improvement. i thought i heard that macpython recently made this "fix", why is the windows version lagging on this? as for some of the questions you posed... i was thinking the name would be important. for each installed package you have a single file with the name of the package (and some appropriate extension maybe). the file would just contain the PKG-INFO with the list of installed files at the end? (is that enough information?). then it becomes simple to see if and what version of a package is installed. perhaps the name should be case-INsensitive. so there is no confusion between "Numeric" and "numeric". things that would take longer with that setup is to find which package a file belongs to, which packages are dependent on a given package, and that sort of stuff. obviously there will need to be some sort of "packages" module in standard python that has functions to perform all these tasks. it should also include a commandline interface so it can be simply accessed by users... (forgive the name, if that sort of thing has been done to death) pyckage.py list #list installed packages pyckage.py update pygame #get latest version of pygame pyckage.py update * #get latest version of all packages pyckage.py showdeps Numeric #you get the idea? anyways, perhaps the PEP should list what functions are available and how they would be accessed on the commandline (or is that too much detail for a PEP?) oh, one last thing to consider... at this point, my package has been put into several different binary packages, RPM and DEB for example. we need to figure something out here. perhaps an installed package can be marked "Not Under Python Package Control", so it can't be removed or updated from the python package stuff. perhaps we could be more flexible and allow the package to embed commands to do these things for it? "uninstall_command" could be set to something like "apt-get remove pygame"? on the other hand, if a really nice package management system is in place, we may no longer need to rely on OS tools to do the packaging for us? hmm, same with windows too. if a user installs a package with the a distutils executable bdist, it adds some entries to the registry to allow the user to uninstall it. if this python package management uninstalls the package, should there be some sort of hook so it can clean out the registry keys too? whew, a lot of things here. perhaps they don't all need to be addressed by the PEP for now, but as long as they are tickling in the back of someone's head as this gets developed i think we'll be in a much better position :]