[Distutils] Pre-pre-PEP: Requirements for the Python BUILDS Specification

[Phillip J. Eby]

At 10:04 AM 10/7/2008 +0100, Paul Moore wrote:
>2008/10/7 Phillip J. Eby <pje at telecommunity.com>:
> > In the case of BUILDS, I propose to do the same: define a standard whose
> > cost/benefit ratios are ideally balanced for each participant.  This does
> > not, by the way, mean that everybody ends up with the same cost/benefit
> > ratio; it simply means that the cost/benefit ratios are best for those
> > people whose participation is most required for the standard to be widely
> > adopted.
> >
> > You can see that this is also what I did in the design of easy_install and
> > setuptools, except that in that effort I only considered developers and
> > users, not system packagers.
>
>I'd argue (you may differ) that the most significant area where you
>missed the mark on user benefits with easy_install and setuptools is
>the lack of easy *uninstall* and easy *list* options.

Well, I'd certainly agree that those features are desirable.  But I 
didn't "miss the mark", in that those features were not part of my 
mark.  ;-)  The goal was to get widespread adoption by developers, 
and thus the primary target audience was developers.  Any features 
that attracted users were there only insofar as the benefit to users 
would specifically drive adoption by developers.

And that means that features that only matter *after* you have things 
installed (i.e., easy uninstall and list) were of relatively little 
importance in the initial feature set.  It was only necessary to 
provide the *possibility* of uninstall and list features, and then 
allow others to scratch the resulting itches.

Now, for BUILDS, the situation is different.  Just as setuptools' 
competitor was distutils, BUILDS' competitor is setuptools.  So, 
BUILDS has to offer developers a switching benefit.  And, unlike the 
situation before, now developers are much more likely to have a lot 
of packages they'd like to list or uninstall, so such features have 
considerably more value now, than they did then, which makes them 
worth putting some effort into.

Also, since that switching benefit is largely going to come from 
having better management tools, the management tools need to be easy 
to build (so that people will build them).

However, since system packagers are experiencing pain right now wrt 
Python packages, there is at least some benefit to their 
participating in the process.  Back when setuptools was developed, 
people from the distros weren't hanging out here in the 
distutils-sig...  or at least, they never answered any of my calls 
for interested parties.


>  Most of the
>issues I hear from users about setuptools (filtered by my prejudices,
>admittedly) is that there's no management options (which brings in the
>system packagers, and their concerns).
>
>Can I suggest that this be included somehow in the new spec, so that
>metadata is available to make wtiting uninstallers and listers as easy
>as writing installers?

Since the single most important part of BUILDS (and the part that 
should be done first) is an installation manifest for packaging tools 
to know what files are of what kind and where, it should be easy for 
uninstallers to work.

Regarding listers, there are already a number of them available in 
the Cheeseshop, and if you're working with Python 2.5+ (and not using 
an older distro that deletes .egg-info files), they should also work 
with distutils-installed packages.

The idea behind the installation manifest and metadata (the "IL" and 
"DS" of BUILDS) is that it should be possible for anyone to write 
their own management tools for specific scenarios, and not have to 
rely on a bunch of implementation-specific and not-very-well-documented stuff.

(It should also be possible, given the "IL" part, to make a distutils 
and/or setuptools command that generates this data from a 
sufficiently well-behaved setup.py.)