[Distutils] Requirent specifiers specified? :)

[Jim Fulton]

I think you are making a mistake to assume that everyone has the same  
notion of obvious
that you do.  For example, someone could reasonably expect that ==1.0  
matches 1.1.1.
(I'm not advocating this interpretation, but simply pointing out that  
"obvious" is not
universal.)

In addition, people sometimes make typos.  A system that figures out  
what they "really meant"
rather than complain when they enter something that doesn't make  
sense isn't doing them any
favors.

In any case, I expect that having people build tools on top of  
setuptools is a use case
you anticipated.  For people to do that, they sometimes need precise  
specifications
of behavior.

Jim

On Jun 22, 2006, at 4:36 PM, Phillip J. Eby wrote:
> At 04:08 PM 6/22/2006 -0400, Jim Fulton wrote:
>>>> So given:    >1, <3, >5, <7
>>>> You are sure that 4 is accepted?
>>>
>>> Scanning left to right, >1 is a lower bound and 4 is above it, so
>>> that's a tentative accept.  Next we see <3, and it is an upper
>>> bound, and we fall below it, so it is a sure accept at that point,
>>> and we stop scanning.
>>
>> Huh? 4 is below 3?
>
> Hm, somehow I got confused with 2.  It should say, <3 is an upper  
> bound, 4 is above it, tentative reject.  >5 is a lower bound, 4 is  
> below it, it's a sure reject.  I think I copied 2 in from another  
> example while editing.
>
>
>>>> Given:  <2, <5
>>>> Is 3 accepted or rejected?
>>>
>>> <2, upper bound, 3 is above, tentative reject.  <5, upper bound, 3
>>> is below it, sure accept.  (Intuitively -- at least for me -- <5 is
>>> paired with >-infinity here.)
>>
>> OK.  I think that many people would find this non-obvious.
>
> You keep missing the big picture.  The algorithm is designed to  
> interpret a *meaningful* list of versions *specified by a human*.   
> Humans are usually not excessively redundant, and will thus tend to  
> express a version requirement in the form of ranges with exceptions.
>
> Humans tend to think that it is obvious that if they ask for a  
> version <5, they do not need to also specify that the version be  
> more than negative infinity, or even that it be greater than zero.   
> It is, after all, a *version* number.  :)
>
> Similarly, if I ask for a version >10, I assume that you will  
> understand I want it to be less than negative infinity.  :)
>
> If it weren't for the fact that '.' and '-' are often used in  
> version numbers, I might have used range expressions using '-' or  
> '...', but these are also harder to read for the most common case  
> where you want '>=someversion'.
>
>
>> Ah, so in your explanation above, "f the version falls below a lower
>> bound"
>> only applies to a scanning position.  OK, that clarifies this case.
>
> If you look back at my previous descriptions, the concept of  
> scanning is repeated many times, including the simple 1-paragraph  
> description.  It's all scanning, just like a human would do when  
> reading a series of version requirements.
>
>
>> I think that the fact that you need to understand a non-trivial
>> algorithm
>> with a state machine to understand how non-trivial specifications are
>> interpreted is a problem.
>
> It's only a problem if you try to reduce it to an algorithm.  If  
> you simply try to *understand* a version requirement, it's really  
> quite straightforward.  Think of what the human who wrote the  
> requirement is saying:
>
> "Um, let's see, it should be less than version 3, because that  
> version's got a new API, and it should be more than version 1.2,  
> because there were some bugfixes, and oh yeah, don't use version  
> 1.6 because it was just plain hosed.  Oh, and 1.1.3 is also good."
>
> The algorithm is designed to correctly interpret a person who is  
> simply recording their wishes in this manner -- describing a series  
> of acceptable or unacceptable ranges, and mentioning specific  
> versions that are exceptions to the ranges.
>
>
>>   Maybe it's enough to tell people "don't
>> use complex specifications", but maybe it would be better to use a
>> simpler system.
>
> People don't normally express themselves redundantly -- especially  
> programmers.  The target users of specifications are these humans,  
> not the programmers trying to interpret the specification for  
> specifications.  I did not anticipate that particular user and use  
> case.  ;)
>

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