[Distutils] easy_install wrong download site preference
P.J. Eby
pje at telecommunity.com
Thu Jul 1 23:10:39 CEST 2010
At 11:36 PM 7/1/2010 +0300, anatoly techtonik wrote:
>On Wed, Jun 30, 2010 at 7:54 PM, P.J. Eby <pje at telecommunity.com> wrote:
> >
> > It prefers newer packages, or, if the versions are the same, it
> prefers the shortest download URL. Â In this case, the Google Code
> url is shorter.
>
>That's illogical. Better prefer PyPI if versions are the same.
The "shortest path" logic is there to avoid certain file recognition
problems that occur without it. The special case of PyPI isn't
special enough to break those rules.
>PyPI is that page. Google Code URL homepage doesn't have any Python
>related downloads at all.
There isn't any way to know that from the filename.
>What if we set download_url instead of
>homepage back to PyPI page - will it satisfy setuptools as a quick
>fix?
No. You'd need to remove the current "home_page" setting, or point
it elsewhere.
> (I understand that people do not want to touch setuptools code
>anymore)
That's not really the issue; the issue here is that package
precedence is based on a stable comparison scheme, where it doesn't
make sense to give one location priority over another, as it will
simply lead to someone else complaining about the changed behavior,
because they were relying on a different URL having precedence under
the current scheme.
What's more, even if I made this change and released it immediately
into the wild, you would *still* have this problem for the entire
existing installed base, which is considerable. (Many people have
not upgraded from setuptools 0.6c2 or 0.6c9, which are many years old.)
And, the distribute fork would need to match the behavior as well, or
there's that group of people who may still end up with the wrong
file. Already, AFAICT, distribute has changed (at least in the
repository) the path precedence rules in a way that is not consistent
with the way setuptools does it, for both URLs *and* local file
paths, so I can't really give any guidance as to what their version
of easy_install will do -- it may do the "right thing" in this case,
but if so, it's essentially by accident. (i.e., it won't necessarily
do the right thing in other cases, since their changes weren't
motivated by the same issue.)
(One thing that I *could* do, would be to give precedence to links
with #md5 tags -- this would automatically make PyPI (and PyPI-clone)
links score higher, and would be less likely to introduce problems
than trying to force recognition of PyPI specifically. But this
would still have the problem of getting out into the field in a timely way.)
> > (Note: you will have to go into PyPI's administration interface
> and manually change the home page link for *all past versions* as
> well, due to the way the /simple index works.)
>
>Where is the relevant code for this PyPI? I wonder why it didn't set
>rel="download" for PyPI downloads if it should?
That's not the problem either; easy_install is *finding* those links
just fine; if you use "easy_install -vvn protobuf" you'll see it list
both the PyPI tgz's and the Google Code URLs as candidates; it's just
using the URL length as the tie-breaker.
More information about the Distutils-SIG
mailing list