Why are there //:pants-requirements.txt dependencies?

[jsirois]

requirements-perf/aa/ab/ac/ad/ae/af/BUILD

Line 9 in 278948e

"//:pants-requirements.txt",

[benjyw]

I think because the user that generated this out of their real repo used ./pants dependencies to generate the BUILD files.

[benjyw]

So these deps are explicit, but were generated from the inferred deps in a real repo.

[jsirois]

Ok. So then part of all this is simply the v1 macros problem. Instead of depending on python_requirements / python_requirement_libraries only, there is a dependence on the file that generates them. As such, rules that act on dependencies will get triggered to re-run for any whitespace change.

[stuhood]

pantsbuild/pants#12915 is the relevant ticket then.

[jsirois]

Actually, pantsbuild/pants#12915 aside, we have a second over-invalidation in this case since the pnats-requirements.txt file is set up as a psuedo constraints lockfile, and that file, in whole, is part of the input digest of the resolve process:

requirements-perf/pants.toml

Lines 8 to 10 in 278948e

	[python]
	interpreter_constraints = [">=3.8,<3.9"]
	requirement_constraints = "pants-requirements.txt"

As such, we fully invalidate the cached resolve process on any edit to pants-constraints.txt for 2 independent reasons.

[jsirois]

So a pure-annoyance optimization, since we already fully parse the constraints file anyhow, is to used the parsed constraints to emit a normalized constraints file for the input to the process. This would eliminate whitespace / comment edits in the constraint file invalidating the resolve.

[stuhood]

So a pure-annoyance optimization, since we already fully parse the constraints file anyhow, is to used the parsed constraints to emit a normalized constraints file for the input to the process. This would eliminate whitespace / comment edits in the constraint file invalidating the resolve.

Yea, that makes sense. Because the macro issue alone would not invalidate the resolve (although it might invalidate tests, etc).

[jsirois]

Ok. Small bug in that this is only for the (nearly legacy) psuedo-constraints-lockfile hack. Potentially not worth fixing, but also not hard to fix.

[stuhood]

So a pure-annoyance optimization, since we already fully parse the constraints file anyhow, is to used the parsed constraints to emit a normalized constraints file for the input to the process. This would eliminate whitespace / comment edits in the constraint file invalidating the resolve.

I see an opportunity/necessity to do this as part of pantsbuild/pants#14053