On Sun, Sep 12, 2010 at 9:08 PM, P.J. Eby <p...@telecommunity.com> wrote: > >> https://sourceforge.net/apps/trac/halfcooked/ticket/29 >> >> Gerald is the second package from the last 4 months that I couldn't >> install due to this very obscure behavior, and I suspect there are >> more. > > Gerald installs fine when I try it, and from the same URL (which isn't the > shortest in any case). I suspect you are not using the current version of > easy_install, as the problem shown is due to Sourceforge's use of > '/download' URLs.
It still fails for me and I can explain why. Fail log is attached. The SourceForge URL is longer than the same .egg URL for PyPI package. That's why setuptools choses SF instead of PyPI. But because SF URL doesn't end with .egg setuptools fails to install it. Seems like setuptools is crawled with roaches. =) > That issue was fixed in October 2009, so you are likely using something > <0.6c11. I am using setuptools-0.6c11-py2.6.egg on Windows Vista. > (Or perhaps you are using distribute, which has still not applied this bug > fix almost a year later.) Oh no. I am not one of those heretics. =) >> Phillip, could you, please, still run through your archives to success >> in explaining why this logic of choosing a shorter download URL is >> necessary? I'd really to see what packages benefit from it, > > It was originally added for PIL and other effbot-released packages; it's > retained because to change it now would introduce random breakages to other > projects, in order to benefit one whose source filenames are ambiguous > anyway. This argument is a little bit misleading. Do you really think that PyPI preference over remote site for the same package version will break anything? >> I believe Google protocol buffers popularity alone is enough to change >> the behavior. > > Right now, the naming of the two source distributions is ambiguous, even for > humans. "even" is not the right word here. For humans there is a lot of context information that allow them to choose correct download. Unfortunately, packaging tools are not that smart even if pretend to be so. > Note, however, that since the full source distribution *also* includes the > python code, all that's needed is to change its setup.py slightly and move > it to the root of the source tree. If the Python was the only code inside - that'd be acceptable, but it seems like the proper fix lies in setuptools AI code. Thanks for support. -- anatoly t.
gerald_install.log
Description: Binary data
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
