[Distutils] Package DB: strawman PEP

[Pete Shinners]

> 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 :]