[Distutils] Requirent specifiers specified? :)

[Phillip J. Eby]

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