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

[Carl Banks]

On Jun 1, 4:47 am, 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.
>
> 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:

Oh boy.


> (1) Should setuptools be standard?

Shamelessly speaking as someone who does no wish to enter this
particular niche of Python: I would hope the Python community can do
better.


> (2) What bugs you most about the current featureset?

1. setuptools will download and install dependencies on the user's
behalf, without asking, by default.  It can be disabled, but I think
it's extremely rude: it should ask by default.

2. One cannot simply import modules from packages that use
entry_points: you have to go through package resources.  Very
annoying.

3. Tools such as py2exe don't work with packages that use entry_points
except with some hand tweaks (at least as of the last time I tried).
One might suggest that py2exe should learn how to include setuptools
models, but I don't think people who write tools like py2exe ought to
be burdened with it.  py2exe was possible because the import mechanism
was theretofore so straightforward.

FWIW, I've abandoned usage of a package that used entry points because
of this issue.


> (3) Which features do you need the most (list in order of need)?

Not that my needs are all important, but:

1. Works.
2. Ability to install to unusual locations (BIG)
3. Packages can be installed separately by hand if the user so desires
(copying to site directory, hand editing if necessary)
4. Ability to easily specify compiler options when rebuilding
extension modules.
5. Handles data files reasonably


> (4) Shouldn't we just port gems to python?

Fine with me, some new blood would be useful here.


> (5) What's the best community process to improve setuptools?

Have the BDFL declare that it's the official Python package manager.
Of course, I hope if it ever comes to that the BDFL will pronounce
something else to be the official Python package manager, preferrably
something that isn't based on distutils.


> Hope this discussion can be constructive. In any case, I do appreciate
> the effort that went into creating setuptools (Thanks Phillip J.
> Eby :-). It's existence is clearly better than otherwise.


I don't agree.  It's probably better than otherwise for enterprise
applications, which is the environment for which it was designed.  For
instance, entry points and dependency bookkeeping are useful in such
environments, since there are policies to ensure consistent and
reasonable usage.

For open source, mom-and-pop operations, and other smaller projects, I
think it adds a whole lot of complexity over what otherwise is a
simple thing.


Carl Banks