Re: [Distutils] please fix easy_install shorter URL preference (Was: easy_install wrong download site preference)
At 12:08 PM 9/12/2010 +0300, anatoly techtonik 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. That issue was fixed in October 2009, so you are likely using something <0.6c11. (Or perhaps you are using distribute, which has still not applied this bug fix almost a year later.)
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.
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. 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. (The changes needed would consist of adding 'package_dir={"":"python"}' to the setup() options, and changing relative path uses in the setup.py so that they don't assume the current directory is the 'python' subtree... i.e., mainly just changing all '../src' occurrences to 'src'.) In the alternative, calling the release that contains all languages 'protobuf-all-2.3.0.*' rather than 'protobuf' would also fix the issue.
On Sun, Sep 12, 2010 at 9:08 PM, P.J. Eby <pje@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.
participants (2)
-
anatoly techtonik -
P.J. Eby