[Distutils] Mystery solved

Jim Fulton jim at zope.com
Tue Jul 11 17:50:04 CEST 2006

On Jul 11, 2006, at 11:25 AM, Phillip J. Eby wrote:

> At 03:54 AM 7/11/2006 -0400, Jim Fulton wrote:
>> On Jul 10, 2006, at 6:22 PM, Phillip J. Eby wrote:
>>>>> Here's the problem.  Reducing everything to info messages means
>>>>> there's effectively no control over output detail.  I generally  
>>>>> use
>>>>> 'warn()' for things that *may* reflect an error in input
>>>>> parameters.  So, my take on the above is that although the
>>>>> "Scanning" message could become an info(), the previous one
>>>>> shouldn't.
>>>> This means that one always has to use an index.  In which case,  
>>>> what
>>>> is the point of find-links?
>>> The point of --find-links is to provide links to unindexed packages.
>> But if you use an unindexed package, you'll get a warning.
> Which means it *may* be an error.  See above.  If it was an error,  
> it would be an error.  The point of a warning is to inform you that  
> something *may* be an error.
>> IMO, you should not get a warning for correct use of software.  Users
>> should try to make warnings go away.
> Repeating it doesn't make it so.  I'm not convinced that this  
> particular warning (that you may have misspelled the package name  
> because it's not in the index you're using) is in any way harmful.

It is definitely so.  That is definitely my opinion. :)

OK that's an interesting point wrt possible misspellings. If you can  
find the package via the find links, but not via the index, that  
seems to me to be a pretty good indication that this is not a  
misspelling.  This is the case I'm worried about.  If the package  
can't be found anywhere, then I agree that a warning is warranted.

>>   If you give people warnings that
>> they shouldn't make go away,

That wasn't clear.  If people are using the software correctly, but  
choosing to find distributions via find-links rather than an index,  
and they get warnings, then they will always get warnings and tend to  
ignore them.

> Huh?  They can put the package in the index, use a different index,  
> not use -U, specify an exact download URL (either directly or via -- 
> find-links), etc.  There are a huge number of ways *not* to  
> encounter that particular warning.

I have to use -U to get newer versions of distributions, even if I  
happen to store distributions in a directory that is not a valid  
index.  In this case, I use find-links and -U together, and I'll get  
a warning unless I put distributions in an index.

>> Either you can't have valid unindexed software, or setuptools  
>> shouldn't
>> generate a warning if software isn't in the index.
> This is back to argument by assertion.  Please explain to me why  
> this warning is actually bad, rather than simply asserting that  
> it's so.

I assert and take as a premise that when users are using software  
correctly, including not misspelling anything, they should not get a  
warning.  If you can't buy that, then we have an unreconcilable  

The specific case, which I'll repeat from above, as clearly as I can,  
is this:

- A user chooses not to store their software in an index.
- The user places distributions on a web server somewhere.  This is  
just a directory, it is not a valid index.
- The user points at their server using find-links
- The user has an installation and they want to check for newer  
- The distributions that they are looking for newer versions of can  
be found on the server that they name via find-links.

In this case, they will get a warning that the distribution they are  
looking for couldn't be found on the index.  They didn't misspell  
anything, as setuptools should be able to deduce from the fact that  
their distribution was found on the link server.
I don't think that they should get a warning.  As far as I'm  
concerned, this means that distributions must always be stored on  
index servers and the find-links is just an attractive nuisance.

>> I really find the distinction between indexes and find-links rather
>> puzzling.
> --find-links is used to allow you to point easy_install to a  
> project's non-indexed home page or download page to find links, or  
> to provide other easy_install-processable links, without needing an  
> index.

But they are unusable without getting warnings whenever you want to  
check for updates.

>> Personally, I'd like to find a way to merge these two concepts  
>> into one
>> by choosing a definition of an index that admits a directory full of
>> distributions.
> Feel free to try to come up with one.  However, --find-links allows  
> *multiple* links to be specified, and it is also the basis for the  
> "dependency_links" argument to setup().  --find-links is also a  
> primitive upon which the index facility is built, since index pages  
> are treated more-or-less like --find-links URLs that are  
> automatically generated.

I don't need to, you already did....

> At a minimum, merging the concepts would mean allowing multiple  
> index URLs, or else eliminating the idea of an index,

Yup. Sound good to me.

> and treating all --find-links URLs as though they were the base URL  
> of a package index.


>   If you did that, however, it brings in the question of which of  
> the --find-links URLs should be checked for a /projectname/  
> subdirectory.  All of them?  Just the first one that finds a  
> result?  None of them, if some other criterion is met?

I would stop when a result is found.

> Currently, a remote package search means that all --find-links  
> pages are checked, and the --index-url is searched (by going to  
> "index_url/projectname/").

What is the use case for spreading distributions over multiple  
servers?  Do people really want to do that? I can see providing  
multiple places to look, because different distributions might be on  
different servers, but I don't see why distributions for a single  
project should be spread over multiple servers.


Jim Fulton			mailto:jim at zope.com		Python Powered!
CTO 				(540) 361-1714			http://www.python.org
Zope Corporation	http://www.zope.com		http://www.zope.org

More information about the Distutils-SIG mailing list