https://pantsbuild.org/ logo
Join Slack
Powered by
Is it possible to configure `interpreter_constrain...
# general
g
Is it possible to configure 
interpreter_constraints
in combination of 
parametrize
for resolvers? This is not valid syntax, but it illustrates the point:
Copy code
__defaults__(
    all=dict(
        resolve=parametrize(
           "service-a",
           "service-b",
           "service-c",
           "service-d",
        ),
        # is it possible to say:
        interpreter_constraints={
          "service-a": [
              "CPython == 3.9.*"
          ]
          "default": [
            "CPython == 3.9.*",
            "CPython == 3.10.*",
          ]
        }
    )
)
Like if I want to have a specific constraint for a specific resolver, because for example 
service-a
ONLY works on python3.9, and in that context the resolves for 
service-a
does not need to solve for 
3.10
because is never used. But the same library also works in 
3.10
and the 
3.10
version does gets used by the other services. This is the type of error that I’m getting, and I understand the suggesting, but from the context of 
service-a
it should not try to solve for 
3.10
Copy code
14:02:08.86 [ERROR] 1 Exception encountered:

Engine traceback:
  in `test` goal

InvalidLockfileError: You are consuming `assertpy~=1.0`, `msgpack`, and 2 other requirements from the `service-a` lockfile at 3rdparty/python/resolvers/service-a.lock with incompatible inputs.



- The inputs use interpreter constraints (`CPython==3.10.* OR CPython==3.9.*`) that are not a subset of those used to generate the lockfile (`CPython==3.9.*`).

- The input interpreter constraints are specified by your code, using the `[python].interpreter_constraints` option and the `interpreter_constraints` target field.

- To create a lockfile with new interpreter constraints, update the option `[python].resolves_to_interpreter_constraints`, and then generate the lockfile (see below).

See <https://www.pantsbuild.org/2.20/docs/python/overview/interpreter-compatibility> for details.

To regenerate your lockfile, run `pants generate-lockfiles --resolve=service-a`.

See <https://www.pantsbuild.org/2.20/docs/python/overview/third-party-dependencies> for details
well.. almost having nested parametrization is not supported
Copy code
__defaults__(
    all=dict(
        **parametrize(
            "py310-compat",
            resolve="service-a",
            interpreter_constraints=[
                "CPython == 3.9.*",
                "CPython == 3.10.*",
            ]
        ),
        **parametrize(
            "py39-compat",
            resolve=parametrize(
                "service-b",
                "service-c",
                "service-d",
            ),
            interpreter_constraints=[
                "CPython == 3.9.*",
            ]
        )
    )
)
I suppose the alternative is to unpack N parametrize calls with the duplicates of interpreter constraints but different resolve.
b
Maybe @curved-television-6568 knows a lot about 
parametrize
expert and thus might have insight on this case
c
yea, parametrize in a 
**parametrize()
is currently not supported.
g
Wow! PR and everything! I hope this is well received by the rest of the maintainers! Thank you!!
👍 1
Awesome! I’ve just tested and it works great! With only one small catch which I’m not sure if is expected or not
If I setup my defaults like:
Copy code
__defaults__(
    all={
        **parametrize(
            "py310-compat",
            resolve="service-a",
            interpreter_constraints=[
                "CPython == 3.10.*",
            ]
        ),
        **parametrize(
            "py39-compat",
            resolve=parametrize(
                "service-b",
                "service-c",
                "service-d",
                "service-e",
            ),
            interpreter_constraints=[
                "CPython == 3.9.*",
            ]
        )
    },
)
I get the following error:
Copy code
15:23:08.92 [ERROR] 1 Exception encountered:

Engine traceback:
  in `list` goal
  in Find targets from input specs

InvalidTargetException: libraries/clients/foo-client-x: Unrecognized field `interpreter_constraints=('CPython == 3.9.*',)` in target libraries/clients/foo-client-x:reqs#numpy@parametrize=py39-compat,resolve=service-d. Valid fields for the target type `python_requirement`: ['_find_links', 'dependencies', 'description', 'entry_point', 'modules', 'requirements', 'resolve', 'tags', 'type_stub_modules'].
I can make the error go aways if I do this more _verbose_/_specific_ alternative (and this works!):
Copy code
__defaults__(
    { (python_sources, python_tests): dict(
        **parametrize(
            "py310-compat",
            resolve="service-a",
            interpreter_constraints=[
                "CPython == 3.10.*",
            ]
        ),
        **parametrize(
            "py39-compat",
            resolve=parametrize(
                "service-b",
                "service-c",
                "service-d",
                "service-e",
            ),
            interpreter_constraints=[
                "CPython == 3.9.*",
            ]
        )
    ),
      (python_requirement, ): dict(
            resolve=parametrize(
                "service-a",
                "service-b",
                "service-c",
                "service-d",
                "service-e",
            ),
      )
     }
)
I was under the impression that the 
all
keyword should take care of this type of situations, is it failing because of the new parametrize functionality? Or am I missing something? (BTW I can also follow up in the PR if preferred)
c
Nice! Please file as a new bug report ;) It indeed is due to the new parametrize group thing hiding fields from defaults that should’ve been filtered.. 😝
Good find on the valid work around as well 👍
3 Views
Open in Slack
PreviousNext
Powered by