At 10:04 AM 10/7/2008 +0100, Paul Moore wrote:
2008/10/7 Phillip J. Eby <[EMAIL PROTECTED]>:
> 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.)
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
