At 06:49 PM 11/19/2007 +0100, Martijn Faassen wrote:

Hey,

On Nov 19, 2007 6:31 PM, Phillip J. Eby 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 expressions?

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.

Regards,

Martijn