https://pantsbuild.org/ logo
Join Slack
Powered by
Hello. I've been using Pants for quite a long time...
# general
n
Hello. I've been using Pants for quite a long time, but so far I only used one Python version for all packages within a repo. Now, for a repo with several packages, I need to use different version for one of the packages - most packages should use Python 3.11, one should be using 3.12 (arcor2_ur). There is a problem that one of the important 3rd party dependencies is 3.11 only, so I can't simply migrate all packages to 3.12. So, I set 
interpreter_constraints = ["==3.11.*", "==3.12.*"]
in pants.toml, then constraints to "3.12" in the new 3.12 package and constraints to "3.11" in the package (arcor2_scene, arcor2_calibration) that depends on that 3.11 3rd party lib (open3d) and left other package as they were. Now I'm getting into errors like this one: `InvalidFieldException: The target src/python/arcor2/object_types/tests/test_generic.py has the 
interpreter_constraints
('==3.11.*', '==3.12.*'), which are not a subset of the 
interpreter_constraints
of some of its dependencies:` 
* ('==3.11.*',): src/python/arcor2_scene/scripts:scene
`To fix this, you should likely adjust src/python/arcor2/object_types/tests/test_generic.py's 
interpreter_constraints
to match the narrowest range in the above list.` ...which probably can't be solved easily, as a lot of other packages has 
src/python/arcor2_scene/scripts:scene
as runtime dependency. Am I missing some easy solution or does this situation don't have an easy solution? 🙂 If anyone is interested to take a look, the code is here: https://github.com/ZdenekM/arcor2/tree/ur. I hope I was able to describe situation enough, it is on the edge of my knowledge of Pants...
b
Despite being a list, I think interpreter constraints generally work better with a single one. For this, it'd be something like 
interpreter_constraints=[">=3.11,<3.13"]
. But... I think that's not the core problem.
👍 1
I think when there's a file 
a.py
imported by 
b.py
(i.e. 
import a
), 
b
's interpreter constraints need to be compatible with (subset of) `a`'s. Each target takes its default from the 
pants.toml
file (no matter what they import), i.e. 3.11 or 3.12 in this case. It seems like some targets are constrained, and not all of the things that import them have the same constraints, i.e. they're using the more permissive defaults. I think two options are: 1. update all the downstream targets to match 2. split the different libraries into different resolves, and use https://www.pantsbuild.org/stable/reference/subsystems/python#resolves_to_interpreter_constraints If the libraries are truly separate (never do Python imports of each other directly, but using 
runtime_package_dependencies
between them should be fine).
For option 1, plugging through the various 
BUILD
files like this diff got 
pants peek ::
working for me.
interpreter_constraints.diff
n
@broad-processor-92400 Awesome, thank you for the explanation and for the diff - it works! Yeah, libraries are independent and I use 
runtime_package_dependencies
for integration tests - I was not sure what effects it actually has.
2 Views
Open in Slack
PreviousNext
Powered by