Pep 440 question/clarification Version specifiers no "Or" available
Hi all, In the line of recent discussions[1] about releasing some packages only for some versions of Python. I was reading pep 440 and in particular the "Version specifier section". The following sentence caught my eye:
The comma (",") is equivalent to a logical and operator: a candidate version must match all given version clauses in order to match the specifier as a whole.
Is there no way to have an "or" ? It seem to me that it might be useful for package wanting to express compatibility with `2.6`, `2.7` or `>3.3` for example, in the form `=~2.6 <or operator> =~3.3`. I completely agree that the use case is _limited_ and likely rare, I was just wondering if I'm missing something, if it was an oversight and if not if adding a section detailing that "or" was not considered, or that "or" was explicitly not included for X,Y,Z reason would be a good thing. Thanks, -- Matthias [1]:https://mail.python.org/pipermail/distutils-sig/2016-August/029604.html
On Sep 8, 2016, at 6:47 PM, Matthias Bussonnier <bussonniermatthias@gmail.com> wrote:
Is there no way to have an "or" ? It seem to me that it might be useful for package wanting to express compatibility with `2.6`, `2.7` or `>3.3` for example, in the form `=~2.6 <or operator> =~3.3`.
I completely agree that the use case is _limited_ and likely rare, I was just wondering if I'm missing something, if it was an oversight and if not if adding a section detailing that "or" was not considered, or that "or" was explicitly not included for X,Y,Z reason would be a good thing.
There is currently no way to have an or. I don’t think there is any conceptual reason not to have it, except we were attempting to deviate from what was currently accepted as little as possible and the only character that was currently accepted was only ``,``. We did deviate in that the behavior of ``,`` changes somewhat, but the previous behavior was very tricky and hard to explain. In the future I’d actually like to expand upon it but I think that once you add OR you kind of also need to add a grouping operator as well to handle more complex cases besides ones where you only need AND or OR. I think this would probably be a good place to just add a new AND syntax too, and make it something like: `(~=2.6 or ~=3.3) and != 2.6.5` That was more of a shake up then we wanted to do at the time though. — Donald Stufft
Thats right, there is no 'or' operator available today. In addition to what Donald says, Or significantly complicates the resolution job for the resolver: should 'A OR B' prefer A? If B is already installed should it be uninstalled to permit choosing A (aka is it a disjunction? What if A and B can coexist and one part of the graph wants A and one part wants B but there is an A OR B higher up? - if its a disjunction that becomes uninstallable. tl;dr the ramifications of OR are much deeper than those of AND for this problem space, and we don't even have AND solved properly - Issue 988. -Rob On 9 September 2016 at 10:47, Matthias Bussonnier <bussonniermatthias@gmail.com> wrote:
Hi all,
In the line of recent discussions[1] about releasing some packages only for some versions of Python.
I was reading pep 440 and in particular the "Version specifier section".
The following sentence caught my eye:
The comma (",") is equivalent to a logical and operator: a candidate version must match all given version clauses in order to match the specifier as a whole.
Is there no way to have an "or" ? It seem to me that it might be useful for package wanting to express compatibility with `2.6`, `2.7` or `>3.3` for example, in the form `=~2.6 <or operator> =~3.3`.
I completely agree that the use case is _limited_ and likely rare, I was just wondering if I'm missing something, if it was an oversight and if not if adding a section detailing that "or" was not considered, or that "or" was explicitly not included for X,Y,Z reason would be a good thing.
Thanks, -- Matthias
[1]:https://mail.python.org/pipermail/distutils-sig/2016-August/029604.html _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On 9 Sep 2016 12:32 pm, "Robert Collins" <robertc@robertcollins.net> wrote:
Thats right, there is no 'or' operator available today.
In addition to what Donald says, Or significantly complicates the resolution job for the resolver: should 'A OR B' prefer A? If B is already installed should it be uninstalled to permit choosing A (aka is it a disjunction? What if A and B can coexist and one part of the graph wants A and one part wants B but there is an A OR B higher up? - if its a disjunction that becomes uninstallable.
Fedora started running into this kind of problem when rich dependencies were added to RPM. Between that and the need for compatibility with older RPM versions, it's been genuinely difficult for publishers to start relying on the new features.
tl;dr the ramifications of OR are much deeper than those of AND for this problem space, and we don't even have AND solved properly - Issue 988.
Disjoint environment markers provide most of the capabilities we actually need (like installing one dependency on Py2 and a different one on Py3) without ever forcing the resolver to make an arbitrary choice between them. There are currently some bugs even in that, though - installing an sdist or wheel directly instead of via a requirements file bypasses the environment marker checks for its direct dependencies :( (Steve Kowalik was trying to figure that one out at the PyCon AU sprints, but I don't believe he was able to track down where the missing check should go) Cheers, Nick.
-Rob
On 9 September 2016 at 10:47, Matthias Bussonnier <bussonniermatthias@gmail.com> wrote:
Hi all,
In the line of recent discussions[1] about releasing some packages only for some versions of Python.
I was reading pep 440 and in particular the "Version specifier section".
The following sentence caught my eye:
The comma (",") is equivalent to a logical and operator: a candidate
version must match all given version clauses in order to match the specifier as a whole.
Is there no way to have an "or" ? It seem to me that it might be useful for package wanting to express compatibility with `2.6`, `2.7` or `>3.3` for example, in the form `=~2.6 <or operator> =~3.3`.
I completely agree that the use case is _limited_ and likely rare, I was just wondering if I'm missing something, if it was an oversight and if not if adding a section detailing that "or" was not considered, or that "or" was explicitly not included for X,Y,Z reason would be a good thing.
Thanks, -- Matthias
[1]:
https://mail.python.org/pipermail/distutils-sig/2016-August/029604.html
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On 9 September 2016 at 15:10, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 9 Sep 2016 12:32 pm, "Robert Collins" <robertc@robertcollins.net> wrote:
tl;dr the ramifications of OR are much deeper than those of AND for this problem space, and we don't even have AND solved properly - Issue 988.
Disjoint environment markers provide most of the capabilities we actually need (like installing one dependency on Py2 and a different one on Py3) without ever forcing the resolver to make an arbitrary choice between them.
Yup :) and we've got that pretty solidly adoptable now - chunk of work that it was ;).
There are currently some bugs even in that, though - installing an sdist or wheel directly instead of via a requirements file bypasses the environment marker checks for its direct dependencies :(
(Steve Kowalik was trying to figure that one out at the PyCon AU sprints, but I don't believe he was able to track down where the missing check should go)
I didn't mention it before but I should - its my view we should be really conservative about an OR in the dependency language, for the reasons in my earlier email. -Rob
On 9 September 2016 at 13:19, Robert Collins <robertc@robertcollins.net> wrote:
On 9 September 2016 at 15:10, Nick Coghlan <ncoghlan@gmail.com> wrote:
There are currently some bugs even in that, though - installing an sdist or wheel directly instead of via a requirements file bypasses the environment marker checks for its direct dependencies :(
(Steve Kowalik was trying to figure that one out at the PyCon AU sprints, but I don't believe he was able to track down where the missing check should go)
Back on a real computer now, so the relevant bug report for that one: https://github.com/pypa/pip/issues/3893
I didn't mention it before but I should - its my view we should be really conservative about an OR in the dependency language, for the reasons in my earlier email.
Agreed, getting AND requirements, optional dependencies (extras), and explicit conditional installation (environment markers) right is hard enough without getting into the problems of full disjunctive dependencies. We could potentially do a better job of documenting this though - the leap from "either A or B is fine" to having to be more explicit in saying "in these cases, I expect A, in those cases, I expect B" isn't always clear. Cheers, NIck. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (4)
-
Donald Stufft -
Matthias Bussonnier -
Nick Coghlan -
Robert Collins