[Distutils] Mystery solved

[Phillip J. Eby]

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.


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

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.


>then they are more likely to ignore
>warnings
>that you don't want them to.

What warnings?  There are only about 13 left.  :)


>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 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.


>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.

At a minimum, merging the concepts would mean allowing multiple index URLs, 
or else eliminating the idea of an index, 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?

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/").