Now that we've had a lot of useful discussion about Package Manager,
it's about time to start writing a collection of PEPs. Here's some
notes:
Extending PEP-241 ( http://www.python.org/peps/pep-0241.html )
---------------------------
As per Sarwat's suggestion for canonical version numbers, we do have
somewhat of a solution that I was unaware of: the StrictVersion and
LooseVersion classes in distutils.version. LooseVersion will pretty
much allow us to compare arbitrary 1.0a2 vs 1.0b2 version numbers
reliably. If they don't compare reliably or can not be parsed by
LooseVersion, the package author is not following spec and should be
smacked around :)
We need more metadata, here's what we need:
Metadata-Version: needs to be bumped above 1.0
Package-Name: We need something that tells us what the actual name of
the package or module is! Right now the name is arbitrary and doesn't
need to relate to the name of the module in Python.
Depends: (optional) A list of other packages, by Package-Name (which
must by definition follow python module naming guidelines), that this
package depends on.
Extends: (optional) A list of other packages, by Package-Name, that
enhance the functionality of this package (i.e. Crypto extends twisted
by enabling Conch (the SSH2 client/server))
I believe this will be sufficient. However it may be nice to be able
to specify C or C++ libraries that a package wraps or depends on (but
does not include). Ideas?
One thing, related to Package-name, is that we should completely
deprecate the practice where you can install a whole bunch of python
modules flat in site-packages. If you have more than one file that
belongs in site-packages, it should go in a separate folder and be
referenced by a pth file. There should be a 1:1 relationship between
the number of modules+packages in your site-packages, and the number of
modules+packages that you installed.
Discussion of PEP-243 ( http://www.python.org/peps/pep-0243.html )
-------------------------------
PEP-243 proposes a central module repository system for source modules.
We should say that the PIMP system will supplant this because (a) it
could take advantage of a central module repository if available and
(b) it's easier these days to host open source projects anyways (a la
sourceforge). Speaking of sourceforge, we should have special
integration for sourceforge downloads in PIMP (let the user choose a
preferred mirror, display to the use who is sponsoring their download).
It's possible that the scapegoat may choose to come to an arrangement
with the package maintainers such that package maintainers will host
the scapegoat-built binary packages on their site to make it more
economical for scapegoats.
Embrace and Extend PEP-262 ( http://www.python.org/peps/pep-0262.html )
-----------------------------------------
PEP-262 is the holy grail for PIMP, it allows us to develop a sane way
to do package management, especially uninstallation.
For our platform, PEP-262 has one inherent deficiency: INSTALLDB (the
location for receipts) is a fixed location and not a search path. I
propose that we leverage sys.path in our quest to locate the
installation receipt database, that way we can find /System/Library/...
/Library/... /Network/Library/... ~/Library/... or whatever is
appropriate for that particular installation of Python. The
installation database could have a file name that would be unacceptable
as a python package name, such as INSTALL-DB, this way it could not
possibly be confused with an actual package.
I think that we can deprecate the REQUIRES and PROVIDES files by adding
Depends, Package-Name, and Extends to PKG-INFO. I don't think that the
"PROVIDES" file makes a whole lot of sense, unless the strings used in
provides means it corresponds to a definitive module interface. There
is not currently any sort of registry or PEP for this kind of thing, so
it's probably not at all useful. Since we have upgraded PEP-241, we
should also upgrade the Package class in PEP-262 to include the new
metadata.
Our PEP
------------
This is where we describe exactly what PIMP is and does. I'll start on
that sometime later this weekend, and probably write it to the
pythonmac.org wiki so that anyone with ideas can jump in. I'd like
some feedback on what I have here so far before I start, though.
-bob