I'm seeing something surprising when moving from 2.15.0 to 2.16.0rc0. I've moved my tool version management over from specifying

lockfile = lockfiles/foo.lock

for each tool before, to now having an

install_from_resolve = "build-tools"

, as suggested in the 2.18.x deprecation notice. I've written a

requirements.txt

with my tools versions in it, run

pants generate-lockfiles

, and I can see the lockfile is created correctly. However, when I actually try to use the tools (

pants fmt fix ::

), I get a failure about python version constraints which doesn't quite make sense to me:

...
Engine traceback:
  in `fmt` goal

InvalidLockfileError: You are using the `build-tools` lockfile at lockfiles/build-tools.lock with incompatible inputs.



- The inputs use interpreter constraints (`CPython<4,>=3.7`) that are not a subset of those used to generate the lockfile (`CPython==3.9.15`).- The input interpreter constraints are specified by your code, using the `[python].interpreter_constraints` option and the `interpreter_constraints` target field.
...

I haven't specified the inputs' constraints (

<4,>=3.7

) anywhere; I in fact use a fixed python version for everything. My

pants.toml

has:

[GLOBAL]
pants_version = "2.16.0rc0"

[python]
enable_resolves = true
default_resolve = "default"
interpreter_constraints = ["CPython==3.9.15"]

[python.resolves]
default = "lockfiles/default.lock"
build-tools = "lockfiles/build-tools.lock"

[black]
install_from_resolve = "build-tools"

# and the same for lots of other tools -- autoflake, isort, and so on

My tools are specified in `/pants/build_tools/`:

# /pants/build_tools/requirements.txt
autoflake==2.0.2
black==22.3.0
flake8==6.0.0
isort==5.11.5
mypy==1.1.1

# /pants/build_tools/BUILD.pants
python_requirements(resolve="build-tools")

The lockfile header mentions my actual interpreter constraint:

# /lockfiles/build-tools.lock
// This lockfile was autogenerated by Pants. To regenerate, run:
//
//    pants generate-lockfiles --resolve=build-tools
//
// --- BEGIN PANTS LOCKFILE METADATA: DO NOT EDIT OR REMOVE ---
// {
//   "version": 3,
//   "valid_for_interpreter_constraints": [
//     "CPython==3.9.15"
//   ],
//   "generated_with_requirements": [
//     "autoflake==2.0.2",
//     "black==22.3.0",
//     "flake8==6.0.0",
//     "isort==5.11.5",
//     "mypy==1.1.1"
//   ],
//   "manylinux": "manylinux2014",
//   "requirement_constraints": [],
//   "only_binary": [],
//   "no_binary": []
// }
// --- END PANTS LOCKFILE METADATA ---
...

Can anyone tell me what I'm doing wrong?

My understanding is that the

pants generate-lockfiles

goal uses the generic python constraints you set in

pants.toml

. However, some tools have their own constraints, and if you don't configure them, it reverts to the Pants default of

<4,>=3.7

. Here's what I had to do in `pants.toml`:

[isort]
config = ["build_support/pyproject.toml"]
install_from_resolve = "isort"
interpreter_constraints = [">=3.8.1,<3.9"]

[black]
config = "build_support/pyproject.toml"
install_from_resolve = "black"
interpreter_constraints = [">=3.8.1,<3.9"]

[flake8]
config = "build_support/.flake8"
install_from_resolve = "flake8"
extra_requirements.add = [
  "flake8-black",
  "flake8-bugbear",
  "flake8-pantsbuild",
  "yesqa"
]

[yamllint]
config_file_name = "build_support/.yamllint.yaml"
install_from_resolve = "yamllint"
interpreter_constraints = [">=3.8.1,<3.9"]

Note that flake8 doesn't have an interpreter_constraints field.

thanks for the quick response @acoustic-garden-40182, I think this has largely done the trick!

No worries, I saw a question I might actually be able to answer and jumped on the opportunity haha

I think https://github.com/pantsbuild/pants/issues/15358 might be related. That is, you’re not the only one to hit this rough edge, and it may improve in later versions of 2.16.