[Pythonmac-SIG] Starting a PEP for PIMP

[Bob Ippolito]

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