[Distutils] installation preferences proposal, volunteer to help implementation

Phillip J. Eby pje at telecommunity.com
Mon Nov 19 19:18:13 CET 2007

At 06:49 PM 11/19/2007 +0100, Martijn Faassen wrote:
>On Nov 19, 2007 6:31 PM, Phillip J. Eby <pje at telecommunity.com> wrote:
> >
> > Yes.  What's needed is a way to implement "or" syntax for
> > requirements, so that we can  say "Foo<1.2|Bar==1.3" -- and therefore
> > also say e.g. "B==1.3.1|B>=1.3".
>I'm trying to understand why you'd want to express "Foo < 1.2 | Bar ==
>1.3" - the library with this dependency would try to import Bar and if
>this fails, it'll try importing Foo?
>Why do you use bitwise '|' for this, not 'or' as it used in Python 

Because it's not used by the current syntax, whereas "or" is a valid 
package name.

>One thing that is not very pretty about 'or' syntax for version
>preferences is the repetition of the package name:
>zope.interface | zope.interface == 1.2.3

While syntactically valid, the above is meaningless, since the latter 
requirement implies the former.  The "|" is being used to mean 
"ordered choice" (I suppose "||" would be better in some respects).

>I'd like a shortcut syntax for this, something like:
>zope.interface (1.2.3)
>We could let that be sugar that expands to the same underlying 'or' syntax.

I'm wary of adding too much syntax to requirements.  The meaning of 
the parentheses in the above is entirely inscrutable.

> > In practical terms, this means that what is now Requirement must
> > become a VersionSpec or something of that sort, and a Requirement
> > become an ordered collection of VersionSpec objects.
> >
> > Parsing, naturally, will also change a good bit, as will the
> > resolution algorithm, since right now there is no provision for
> > fallbacks.  Finally, easy_install's core searches will change as well.
> >
> > I don't expect this will be an easy change, even for me.  And it's
> > definitely not going into the 0.6 line, because dependencies in the
> > new syntax won't be readable by older versions of setuptools.
>Yes, I understand this needs to be in 0.7. I do want some basic idea
>that there *will* be a 0.7 in the forseeable future if this work
>happens, though, on the order of months, not years. Of course it's
>understood that this would depend on me actually doing the work. :)
> > You might wonder why we can't implement something simpler that's more
> > narrowly tailored to what you need, but in truth it wouldn't be much
> > narrowed.  The resolution algorithm and easy_install are probably the
> > tough nuts to crack (especially without tests); by comparison the
> > parsing and object issues should be pretty simple by comparison
> > (especially with tests).
>Thanks for the hints. I wasn't expecting it to be easy, and I realize
>that a tailored approach wouldn't make it much simpler (even though I
>would appreciate a syntax for the particular use case).
>I'm not expecting this to be easy, I just want to give it a shot. I
>will be writing tests if it's at all feasible. I like tests.

More information about the Distutils-SIG mailing list