This is an archive of the discontinued Mercurial Phabricator instance.

hghave: add pyXY features for Python version numbers
ClosedPublic

Authored by indygreg on Oct 13 2018, 10:53 AM.

Details

Summary

This will allow us to sniff for Python >= versions in tests.

Diff Detail

Repository
rHG Mercurial
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

indygreg created this revision.Oct 13 2018, 10:53 AM
indygreg updated this revision to Diff 12096.Oct 13 2018, 11:00 AM

Is there a way for me to specify something like "<=3.5" and "3.6<=" or similar?

Is there a way for me to specify something like "<=3.5" and "3.6<=" or similar?

Adding no- to the capability name will invert the condition. e.g. 3.5 will test false for no-py27 and no-py35 and true for no-py36 and no-py37.

If that is too confusing (I can make an argument it is), we could add a 2nd hghave series for the <= check. Say pymax27, pymax36 etc.

Is there a way for me to specify something like "<=3.5" and "3.6<=" or similar?

Adding no- to the capability name will invert the condition. e.g. 3.5 will test false for no-py27 and no-py35 and true for no-py36 and no-py37.
If that is too confusing (I can make an argument it is), we could add a 2nd hghave series for the <= check. Say pymax27, pymax36 etc.

Ah, so I could do (no-py27 no-py35 !) I suppose. Doesn't help with the other half, but it's still only three lines...

I'm not opposed to the patch, but I'm a little wary of it - so far we only have one use case and I already worked around that with an (re) line instead.

Ah, so I could do (no-py27 no-py35 !) I suppose. Doesn't help with the other half, but it's still only three lines...

(no-py27 no-py35 !) would be "<2.7 & < 3.5", which would only be true for <=2.6. You'd want no-py35 to say "Python 2.7 only" for example.

I'm not opposed to the patch, but I'm a little wary of it - so far we only have one use case and I already worked around that with an (re) line instead.

Explicit annotation of expected differences in behavior is better than e.g. a (re). I'm willing to be that (re) survives long after we drop support for Python 3.6 in several years...

I still don't love this, but I'm landing it to make forward progress on 3.7. :/

This revision was automatically updated to reflect the committed changes.