pants: Pants no longer respects flagged interpreter constraints in repl.py task
Previously, ./pants clean-all repl --python-setup-interpreter-constraints="['>3']" <target> on a 2/3-comaptible target (such as >=2.7,<4) would select an appropriate interpreter for the repl session in accordance with the supplied constraints. In this case, we would repl with Python 3.
As of 1.15.0rc0+git5c01b701, this is no longer the case, and the option parsing for the repl task completely ignores the flagged option and goes straight to the config default in pants.ini.
To reproduce, checkout a fresh master and run:
./pants clean-all repl --python-setup-interpreter-constraints="['CPython>=3.6']" testprojects/src/python/interpreter_selection:echo_interpreter_version_lib
This should create a repl with Python 3 as indicated by the constraints applied on the cmdline.
During my initial digging, it looks like PythonSetup.global_instance().interpreter_constraints is failing to load the correct value from the cmdline flag and instead contains pants.ini defaults, or the hardcoded default. In interpreter_cache.py and python_execution_task_base.py, calls to compatibility_or_constraints fail to trigger interpreter_constraints as a “flagged” option, and instead proceeding as if we had not passed it on the command line. This first manifests during interpreter selection, and then again when we build a repl pex with the same constraints in python_execution_task_base.py.
And, for reference:
$ ./pants --python-setup-interpreter-constraints="['>3']" options | grep 'python.setup.interpreter.constraints'
python-setup.interpreter_constraints = ['>3'] (from FLAG in pants.ini)
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 16 (16 by maintainers)
Yeah, I think using the global option makes sense. Having different interpreter constraints for different tasks on the same set of targets is not a particularly useful ability. It’s almost never what the user intends, and definitely not worth the confusion.