OR interpreter constraints when multiple given #678
Conversation
This reverts commit f058d1b. Actually it looks like we need to keep meet_all_constraints for the sake of PEX_PYTHON_PATH and PEX_PYTHON.
It looks like we need to keep in some places the behavior of ANDing a list of constraints per pex-tool#654 (comment). But in general we want to OR. If PEX_PYTHON or PEX_PYTHON_PATH are not set, OR.
Per pex-tool#655 (comment), Chris is okay with always ORing. This is a much more consistent and simpler approach, so is ideal over the earlier conditional logic.
Eric-Arellano
changed the title
There was a problem hiding this comment.
This change is fine to make - it will not adversely impact Twitter code. However, is there anything we should do to deprecated this @jsirois? I don't think we need to do anything special but a fair warning might be in order.
Several tests were failing that they could not find a compatibile interpreter for the empty constraints []. We did not originally hit this error because the builtin all() will return True if the iterable is empty. So, we were calling all(matches(filt) for filt in []), which returned True. Now that we use any(), it would return False. Instead, we should only call matched_interpreters() if there are any constraints to begin with.
|
pantsbuild/pants@4d63f8a closed this when it shouldn't have. |
The test was passing multiple interpreter constraints which now get ORed rather than the intended AND. Instead, use one string with a `,` in order to AND as intended.
Py2 was fixed, but Py3 was failing for same reason that we were now ORing when what we want is AND.
There was a problem hiding this comment.
This looks good to me, but It seems like a good time to add a test that the ORing works.
To @CMLivingston's point, this is CLI-API breaking. The practical break out there will be folks using multiple flags in place of one flag and the comma operator. Since PEX has no deprecation policy yet (#584), I'm fine with just fixing the existing CLI-flag docs:
https://github.com/pantsbuild/pex/blob/dbf92a9f1359d280632bb49f2c30508c2c35369a/pex/bin/pex.py#L314-L323
An decent example is here in pants:
https://github.com/pantsbuild/pants/blob/9873b1412b7e343142353b57357dae09895386d2/src/python/pants/backend/python/subsystems/python_setup.py#L29-L35
Two more tests were using constraints to AND still, and I didn't catch them until searching "constraint" in the test file. Should be good now. Add a new test to ensure that multiple constraints OR as expected. Finally, stop using sets because they're non-deterministic!
Explain that it ORs now when you use multiple. Pulled from https://github.com/pantsbuild/pants/blob/9873b1412b7e343142353b57357dae09895386d2/src/python/pants/backend/python/subsystems/python_setup.py#L29-L35.
While sets indeed are non-deterministic when used for things like iteration, checking the equality of two sets is always deterministic! I forgot about this. Restore sets to keep with original code more and because they're more appropriate here than sorted lists.
Problem
Resolves #655.
We would expect a list of constraints, such as
['CPython>=2.7,<3', 'CPython>=3.4'], to OR the separate list entries, i.e. allow an interpreter that satisfies any of these distinct requirement strings. Instead, we always AND lists of constraints.Solution
Always
ORa list of interpreter constraints. If the user wantsAND, they may do so within the single requirement string via,, e.g.'CPython>=2.7,<3'.