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

[rurpy at yahoo.com]

On Jun 1, 2: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:
>
> (1) Should setuptools be standard?

I hope not.  Like many others, I avoid packages
the require installation via setuptools.

My first experience with setuptools (I do not
make much distinction here between setuptools and
packages installed using setuptools) was quite
unpleasant.  It was a couple years ago and I
have forgotten a lot of details but it was roughly:
Downloaded a package from the net, did the usual
"python setup.py install" and got a messages that
I needed to install setuptools first.  (First time
I'd ever heard of setuptools, not idea what it was
or did.)

Machine not on internet so I looked at readme
for other options for installing.  No information
about dependencies, install, easy_install, setuptools
in any of the readme's or other package doc.
Finally found a url buried in one of .py files.
Eventually, from another machine, I got it
downloaded and installed.  Ran it, and then
the dependency issues popped up with no internet
connection, recollection is messages were obscure.
Got internet connection and tried again, never
did it tell me what it wanted to download or the
sizes (internet connection was a modem).  Somewhere
I got a url for setuptools "help" that pointed
the Peak website.  I then had to hunt around for
a long time before finding the setuptools docs.
When I did find them they appeared to be written
for a packaging programmer, not for an someone who
just want to get a package installed so he could
continue with his main task.

The kicker was that after all of this BS, I discovered
that I could install the package simply by copying
it's files to the Python install site-lib directory!
Sheesh!!

I have since used setuptools a few more times and
had problems several times.

Now, my complaint about setuptools is not any of
the specific problems I've had using it -- those
presumably could be (perhaps have been) fixed.
The problem is the disconnect between what I see
as blatantly obvious requirements for any kind of
installer and what setuptools provides.  I consider
the need for locally available usage instructions so
obvious as to not needing mentioning.  I consider
sensible behavior in the face of no, slow, or bad
internet connections obvious.  I consider defaults
(not auto-downloading potentially large files) to
be obvious.  That the the setuptools developers do
not share my world view makes me unable to trust
them.  Perhaps they will silently change some settings
on my machine that I depend on?

Setuptools' philosophy seems to me to be fundamentally
Microsoftian: sit back, relax, we'll take care of
everything (which requires you to effectively give
your machine to us, but please don't worry about that.)
It is a philosophy I detest, and use free software
to get away from.

> (2) What bugs you most about the current featureset?
>
> (3) Which features do you need the most (list in order of need)?

If must *work*, always.

It must have simple, very well written docs, that
are always easily accessible.
Nobody should be expected to become a setuptools
expert in order to install a package, but if they
need to do something out of the ordinary, they
must be able to find out how, quickly and effectively.

It must work reliably and simply in a wide variety
of environments, not just the enviroments the developers
happen to be used to (no, slow, intermittent internet,
unusual install locations, multiple package versions,
multiple python versions, different compilation
environments...)

It's scope should be limited to Python.  There are
OS packaging tools for applications (python or
otherwise), and the ongoing problems with them
(c.f. Fedora's rpm/yum) despite a decade of work
make me doubtful a python centric project that
tried to tackle the problem could get it right.

Need to be able to *manage* packages (remove, list,
maintain info about,...)  as well as install them.

A common way of packaging / installing documentation.
Most of my Python work in on Windows and whenever I
install a Python package (setuptools or otherwise),
I have to look for a sepreate docs package, and if
not exist, download the source package, find the
docs in it, sometimes build them, and if I can't
to that, try to wget the online docs.  Would like
a nerw setuptools to provide the machinery and
conventions to allow packager to easily include
docs in a package and have them installed in a
common, indexed, location on the target machine.
(C.f. Activestate's Perl.)

> (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?