https://pantsbuild.org/ logo
Join Slack
Powered by
why do I get an error for finding the wrong versio...
# general
q
why do I get an error for finding the wrong version of the interpreter when I have specified python 3.10 in my interpreter constraints:
Copy code
# pants.toml
[python]
interpreter_constraints = ["==3.10.12"]
enable_resolves = true

[python.resolves] # TODO: <https://aurisrobotics.atlassian.net/browse/OITS-27659>
python-default = "devops/pantsbuild/lockfiles/python-default.lock"
pants-plugins = "devops/pantsbuild/lockfiles/pants-plugins.lock" # TODO: <https://aurisrobotics.atlassian.net/browse/OITS-27800>

[python.resolves_to_interpreter_constraints]
pants-plugins = ["==3.9.*"]  # TODO: <https://aurisrobotics.atlassian.net/browse/OITS-27800>

[python-bootstrap]
search_path = [
    "<PYENV>",
    "<PATH>",
]
It is saying the error is for the 
check
goal
The error:
w
your plugin directory needs 3.9
q
but according to the docs, the 
check
goal will respect my version of the interpreter:
w
pants-plugins = ["==3.9.*"]
?
q
also, my plugins directory needs 3.9 or pants needs 3.9 to just generate lockfiles?
that is for the pants-plugins resolve
to generate that resolve
the lockfile is already generated
i am trying to run this in CI/CD
and the exception is being thrown my the 
check
goal
by*
w
Do you have something like this in your pants-plugins build file? 
pants_requirements(name="pants", resolve="pants-plugins")
q
yes
w
So, my assumption is that you'd require that resolve and interpreter_constraints for anything operating in that location/folder - since the resolve is setup explicitly for 3.9 Running some tests on a multi-interpreter repo I have
q
but that is what I am confused about. why is the pants-plugin resolve using python 3.9? my interpreter constraints is 3.10.12. I specified 3.9 for the 
resolves_to_interpreter_constraints
property
which, as stated in the docs, shouldn't affect the interpreter constraints
it is just used to generate the lockfiles
w
in-repo plugins need to run on the same version that pants does - which is 3.9
q
Does it mention that anywhere in the docs?
I am not able to find that
w
On that page
q
oh I see. its in the code snippet
but again, it is saying this is for generating the lockfiles
not the in-repo pants-plugins
the reason I am confused is, the docs say 
resolves_to_interpreter_constraints
is used to "Override the interpreter constraints to use when generating a resolve's lockfile" This doesn't imply that the resolve itself uses that interpreter version, or does it?
w
Yeah, so you're in this weird mixed constraints situation - where you have a lockfile generated by 3.9, running on 3.10, Then you have the tooling, like mypy, which probably wants to build a requirements_venv from your lockfile - anticipating using the same tooling as what was used in the lockfile. I'm handwaving here, but I think a decent approach might be something like this? @curved-television-6568 @fresh-cat-90827 - if you think this is a reasonable approach to in-repo plugins, maybe we add it to the docs and force a convention on pants-related code 
pants.toml
Copy code
backend_packages = [
    "pants.backend.plugin_development",
    "pants.backend.python.mixed_interpreter_constraints",
     ...
]

[python]
enable_resolves = true
interpreter_constraints = ["==3.11.*"]

[python.resolves]
pants-plugins = "build-support/lockfiles/pants-plugins.lock"
python-default = "build-support/lockfiles/python-default.lock"

[python.resolves_to_interpreter_constraints]
pants-plugins = ["==3.9.*"]
pants-plugins/BUILD
Copy code
pants_requirements(name="pants")

__defaults__(all=dict(interpreter_constraints=["==3.9.*"], resolve="pants-plugins"))
I think this will follow the principle of least surprise for in-repo plugins
Note: This means that you will have to have Python3.9 and whatever else in your environment - but I think it's worth really enforcing this and trying to avoid possible shortcuts
pants py-constraints ::
should show that everything is using the expected constraint
q
That is helpful and makes it explicit that 
pants-plugins
is using 3.9! It would be nice if you mention that in the docs I have another coworker who has checkout my code and he is able to run my custom goal that I wrote in the 
pants-plugins
and he doesn't have 3.9 in his machine. Doesn't pants come bundled with its own interpreter? is it possible that when my coworker runs the custom goal, it uses that interpreter somehow? Also, 
pants py-constraints ::
is not working for me. Is this a custom goal that I need to specify the backend for?
w
"pants.backend.python.mixed_interpreter_constraints",
Pants does come bundled with its own interpreter when installed via brew, or the curl command (https://github.com/pantsbuild/scie-pants). I'm kinda handwaving here, but functionally you're using a PythonBuildStandalone 3.9
So, the goal is that "pants-stuff" can be figured out and run by pants, but your in-repo code is run by your system interpreter. in-repo plugins are kinda a weird middleground. But again, Im handwaving all the details
q
Yes, the pants-plugins code is using 3.9. Its just that the way it is worded in the docs, it seems 3.9 is just used to generate the lockfiles and not needed for the in-repo plugin code. This brings me to another question, Does this mean 
resolves_to_interpreter_constraints
sets the interpreter constraints for that resolve as well? meaning not only does it using 3.9 to generate the lockfiles, but also for the resolve as well? If not, how does pants-plugins know to use 3.9 if I am not using 
__defaults__(all=dict(interpreter_constraints=["==3.9.*"], resolve="pants-plugins"))
yet?
w
Hard to say without seeing the whole repo. There is another option, which I don't do on in-repo plugins, and you might be able to widen your constraints, so that 3.9 and 3.10 are all lumped in together, but to me - keeping in-repo plugins as their own thing makes more sense
q
yes I agree
c
I think resolves_to_interpreter_constraints applies the same as the regular interpreter_constraints option, that is, it applies to everything that needs an IC, not just lockfile generation. I think the docs meant to say "e.g. for lockfile generation", (with the "e.g." part indicating it not being an exhaustive list of what it is being used for) EDIT: oh, I may be wrong here... given it is explicitly called out with a warning.. I'd have to do more research to know what's going on here then 😛
with that said, I think Pants should open up for using the provided Python for plugins also during plugin development. That only makes sense, as that is the Python it'll be deployed to.
q
Yes exactly
2 Views
Open in Slack
PreviousNext
Powered by