python's setuptools (eggs) vs ruby's gems survey/discussion

[Paul Boddie]

On 1 Jun, 10:47, Alia Khouri <alia_kho... at yahoo.com> wrote:
> Can we open up the discussion here about how to improve setuptools
> which has become the de facto standard for distributing / installing
> python software. I've been playing around with ruby's gems which seems
> to be more more mature and  usable.

I'm sure people also regard Perl's CPAN-related tools and
infrastructure to be more mature and usable, but I'd like to widen the
discussion beyond language-specific package and dependency management.

> From my perspective, the relative immaturity of setuptools and its
> simultaneous widespread use is a clear python weakness and can make
> python less easy to absorb than it should be.
>
> A few questions (please add more) so far are:
>
> (1) Should setuptools be standard?
>
> (2) What bugs you most about the current featureset?
>
> (3) Which features do you need the most (list in order of need)?

I'm not really in your target audience for these questions since I
never use setuptools: instead, I use the Debian-based package and
dependency management provided by my system. If any of the system
packages use setuptools, it's to build packages in such a way that
they resemble classic distutils package installations.

However, I do work in environments where I do have to install packages
to non-system locations manually. Even in such situations, the
packages I tend to use employ a plain distutils-based setup script,
and I'm not completely sure that I'd want to use setuptools/
easy_install, since aside from some dependency management (which I
doubt extends to various non-Python libraries) it doesn't provide
compelling advantages over distutils like uninstallation, for example.

> (4) Shouldn't we just port gems to python?
>
> (5) What's the best community process to improve setuptools?
>
> (6) What's your ideal conception of the 'standard python package
> manager?

Well, I don't deny the utility of a Python package manager given that
it could be useful for people who use systems which don't provide
system package/dependency management (at least in a consistent or
widely-deployed fashion) or who have to work without taking advantage
of system packages (whether it be due to privileges or issues with
decisions taken by the package maintainers), but the most important
thing from my perspective is that it should complement and co-operate
with system packaging activities. Although distutils is often derided
for its architecture and for some odd usability issues, it does take
away a lot of the tedious work required when laying out installations
for subsequent packaging.

Perhaps efforts should be directed towards the distutils type of work,
making it easier to install things like documentation and non-code
resources, potentially even employing a different architecture: once
upon a time, Python libraries were installed using a Makefile-based
scheme, and there are plenty of Makefile-like tools and libraries
written in Python [1]. In addition, there should be efforts which
integrate this packaging with the existing range of package and
dependency managers: it shouldn't be the case that one only considers
a Python-only dependency manager, because that just leads to the usual
reinvention of what has been done before, plus those people packaging
for Debian, Fedora, *BSD and so on won't see any benefit from what has
been done. Indeed, it shouldn't be inconceivable that a Python-only
dependency management solution might be based on existing tools and
infrastructure, rather than trying to figure out issues like
reliability and redundancy all over again.

I note that the overlap between various mature projects of this nature
and the distutils community seems to be minimal. Once again, I suggest
that people take advantage of the expertise and experience built up in
other projects and communities, and not merely those whose products
conveniently resemble a preconceived notion of what such a solution
should be in the Python world. CPAN and friends and all their baggage
are not universally applicable, and any consideration merely of such
solutions will produce a setuptools successor whose relevance is just
as limited as its predecessor.

Paul

[1] http://wiki.python.org/moin/ConfigurationAndBuildTools