Why does

pants tailor ::

not add

python_requirements

target when the

requirements.txt

is referenced under

[python.resolves]

in

pants.toml

?

The string there is meant to be the pants-managed lockfile, which pants uses for things like dependency inference and subsetting. That is, it is indicating where to put the output derived from the requirements targets, not an input. I’m not 100% sure I understand your question though

The lockfiles doc mentions manually generating the lockfile via

poetry export

and then referencing the file directly under

[python.resolves]

Ah yep. I think the expectation for that use case is still having

poetry_requirements

as the “inputs” (to register

python_requirement

targets and allow customising them as required), and then manually generating the required “outputs” but they’re still just the outputs. It does seem plausible that pants could use a manually generated “lockfile” like that as both input and output, although the Pants-managed Pex lockfiles I think are more flexible/faster for pants to work with.

@broad-processor-92400 any tips for the following problem (closely related) We have a bunch of poetry.lock and the most common strategy we employ is

poetry lock --no-update

so many of our lock files have versions of libraries pinned at much older versions than what would be resolved if done today. I was considering updating the pyproject.toml version constraints so they're more conservative, but I didn't know if you had a better idea.

You can use constraints file since pants doesn't support poetry like no update option https://www.pantsbuild.org/2.19/docs/python/overview/third-party-dependencies#constraints-files