[Catalog-sig] RFC: pypan - a Python package manager

[David Ascher]

Thomas Heller wrote:

> The chicken and egg issue. It's difficult to reach the critical mass
> where the system is actually used.
 >
> Question for other readers of this list (David, maybe): How's pyppm
> going? I don't hear much from it.

PyPPM is pretty stagnant.  There are a few problems w/ PyPPM from where I'm sitting.

1) Unlike in the Perl world, we have to manage both the code repositories and 
the binary package building & distributing processes.  In Perl, CPAN exists 
(ActiveState need do nothing there), and PPM is "relatively" easy (it's still 
hard, since many many modules fail to build on some OSes or their reqs aren't 
clear, or ...).  It's a maintenance nightmare.  I'm not convinced that PyPPM 
will live much longer.  I'm very interested in alternatives that provide value 
to our users and that don't have the high maintenance cost.

2) Distutils, while better than nothing, is still very young.  There are (lots 
of) bugs (in codepaths that most people don't touch), but mostly it's not really 
designed to do what we need it to do.  People tend to write setup.py scripts for 
one particular goal ("setup.py install"), and extracting the relevant 
information to get "setup.py makeppd" to work takes a large amount of work for 
each package for each platform.  I argued as hard as I could in distutils' early 
days that we needed a declarative syntax to describe packages rather than Python 
code, but that wasn't chosen.  I still think I was right =).  I realize that I 
could pick up the mantle of distutils and speak with code.  However, changing 
such a fundamental aspect involves more work than it's worth to me right now.

3) The chicken/egg problem hits us hard -- the infrastructure isn't in place,
and putting in infrastructure is expensive.  Making it easier for Python users
to install modules is hardly where ActiveState can expect to reap the largest
rewards for its efforts in our larger picture.

4) The first implementation of PyPPM was sub-par.  I'd rather rewrite it from 
scratch.

5) Distutils is "too" good in some ways.  The windows installers, for example, 
solve the problem well enough for enough users (and, crucially, package 
authors), that there isn't a huge pressure on us to do it better/differently. 
As I've said before, I'm not convinced that Python modules belong at the same 
level of granularity as Python itself, but that's a second-order problem.

Just a few thoughts.

--david