-
-
Notifications
You must be signed in to change notification settings - Fork 631
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pants no longer respects flagged interpreter constraints in repl.py task #7625
Comments
From my initial investigation, it appears that this is not taking place during interpreter selection, and likely manifests earlier during option parsing, as |
It does! But this is a scope issue and you're not going to like it: As you reported the issue, ie:
Using the global scope, ie:
So you can still tell I'm going to close this as answered, but if the scope did change without deprecation - this is a legitimate bug. If you want to pursue the scope change bug and have Pants supply backwards compatibility for the goal (and task?) scopes, that may be worth a new more targetd issue. |
Thanks, John, for the clarification! I will look into whether this was not deprecated properly and follow up. |
Any ideas of where/when this took place? I take it somewhere a subsystem dependency got changed from global -> scoped, but seems like this it affects more than just the interpreter cache. |
Nope, I leave that spelunking to you. This is eminently git bisectable... |
No problem, I was just trying to see if you have any quick thoughts because the bisect + repro required a cargo rebuild for most of the attempts. Finally found it:
So I am clear here, the framing of a new ticket would be to reinstate the old behavior and add a deprecation warning for 2 minor version releases? |
Hmm, looks like we might have a bug that was introduced by #7156. Namely the difference between |
Oops, sorry about that! I don't really know much about subsystem scopes. My initial instinct is that it should probably be scoped to the task, because the task does the resolve and is the thing that cares about platforms. But it kind of feels like this kind of platform constraints specification is a global decision that cuts across multiple tasks, so maybe it should just be a global config that everything uses. So what I guess I'm saying is, I'd like to defer to someone who understands the pants optioning system better than I do. |
The precedent in the codebase is to use the global instance when using PythonSetup, and I think global makes sense given that constraints should apply to all tasks in order to align with interpreter selection + the interpreter product. Allowing different constraints for each task feels like an anti-pattern to me, or a highly specialized use case. Given that detail and the codebase consistency aspect, I think global makes sense. Thoughts here @jsirois ? |
Agreed that as a user I would anticipate interpreter constraints to apply to all tasks. If that wasn’t the case, I would expect the option name to reflect that it’s just for that task, eg It sounds like there wasn’t a specific use case that we were designing for in making it task specific. |
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. |
@Eric-Arellano The full option name does reflect the task scope: This was something that Twitter (and I think, specifically, Brian Wickman) wanted. I'm not sure it's worth it though. I'd be in favor of killing it and requiring fully-scoped flags always. |
There are definitely folks internally who dislike the ability to use short flag names in context. I like it, because it allows things like:
...to be ~10x shorter. But it definitely causes some confusion... and it's possible that in the context of v2, using the abbreviated form would become significantly less useful, since goals will no longer have subscopes. |
I'm pretty strongly against the abbreviation thing, and would love to get rid of it if we can :) |
Closed by #7672. |
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. Ininterpreter_cache.py
andpython_execution_task_base.py
, calls tocompatibility_or_constraints
fail to triggerinterpreter_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 inpython_execution_task_base.py
.And, for reference:
The text was updated successfully, but these errors were encountered: