improving pypi / setuptools

[Alia Khouri]

Due to a recent site overhaul by sourceforge certain files linked to
from pypi won't install. For example, in trying to install all the
dependencies for the subway web framework, I got this kind of error:

<snip>
..
..
..
Searching for CherryPy>=2.1.0-rc1
Reading http://www.python.org/pypi/CherryPy/
Reading http://www.cherrypy.org
Reading http://sourceforge.net/project/showfiles.php?group_id=56099
Best match: CherryPy 2.1.0-rc2
Downloading
http://prdownloads.sourceforge.net/cherrypy/CherryPy-2.1.0-rc2.tar.g
z?download
error: Unexpected HTML page found at
http://prdownloads.sourceforge.net/cherrypy
/CherryPy-2.1.0-rc2.tar.gz?download

</snip>

Unless I am mistaken, this seems like a problem due to a dependency on
screen scraping to get the location of the file. If this is the case,
IMHO it is too fragile.

What ideas do people out there have for making the installation of
python module more reliable?

Just to get the ball rolling, here are two suggestions:

[1] If setuptools encounters an error in retrieving a dependency from
its registered location (off python.org), it falls back to a canonical
URL that serves it from pypi, an email is then dispatched to uploader /
module maintainer, etc...

So I when I register the location of my python module on pypi, I also
upload a copy to pypi. This can serve as a permanent repository for all
python modules and versions, but because it is only used as a fallback
server, bandwidth use and therefore cost will be manageable.

[2] Create an alia for easy_install.py : egg.py

This not really a reliability tweek, its just a memory tweek.

The advantage of this is to save the installer a few
keystrokes, and to relate the installation command
to that which is installed.

Furthermore, I won't be jealous of ruby's little "gem"
command anymore. (-;


AK

 

[Fredrik Lundh]

What ideas do people out there have for making the installation of
python module more reliable?

judging from the support load it's causing me these days, setuptools is a
piece of utter crap. if you want to make things reliable, don't use it.

(if the various "rails" cloners want people to use their stuff, it would be a
lot better is they shipped complete and well-tested source code kits, and
left the packaging to the huge crowd of nice, friendly, and competent
downstream packagers that exist for all major platforms these days. the
downstream folks know what they're doing, and the tools they're using
happens to work. both for the maintainers and for the users.)

</F>

 

[Chris Lambacher]

judging from the support load it's causing me these days, setuptools is a
piece of utter crap. if you want to make things reliable, don't use it.

setuptools is still alpha. Give it another 6months to a year and you will
wonder how we ever got along without it.

(if the various "rails" cloners want people to use their stuff, it would be a
lot better is they shipped complete and well-tested source code kits, and
left the packaging to the huge crowd of nice, friendly, and competent
downstream packagers that exist for all major platforms these days. the

Which downstream packager exists for Windows, or is Windows not a major
platform anymore? Besides many useful modules are not important enough to be
picked up by packagers for some distributions. For instance, Gentoo does not
have RuleDispatch.

 

[Alia Khouri]

It is still early days for setuptools... still, we are lagging behind
the ruby world in this regards.

I definitely agree with you that the so-called megaframeworks need to
be packaged better (especially all versions of the different components
being updated on almost daily basis).

AK