using the python_requirements setup, you can have a requirements.txt that has loose bounds on your dependencies. For first party dependencies you can also configure the following option so that you're distribution dependencies are set to use constrained, but not absolute values. This belongs in the pants.toml:

[setup-py-generation]
first_party_dependency_version_scheme = "compatible"

If you need to then revert to having absolute versions, then you can add the appropriate command line flag in the specific build of your python_distribution to make it to use

exact

. For instance:

pants package --setup-py-generation-first-party-dependency-version-scheme=exact src/python/mypackage:

Additionally, a lockfile can be generated using the

generate-lockfiles

goal. The lockfile will make it so that if you have Pex binaries created from your distribution, that it's guaranteed to have consistent results. I'm also parsing it using commentjson to create constraints to peg my non-pex binary package so I can have repeatable results.

Thanks James for the response. I’ll have to read up on

setup-py-generation

to see if it can be helpful. I’m aware of changing requirements.txt to drop the bounds and the distributed python package will also have the looser bound. My original question is really about people’s workflow. ie what requirement files are manually populated, and what is populated by tools. Today my workflow is manually writing the equivalent of

<http://requirements.in|requirements.in> -- (pip-compile) --> requirements.txt -- (pants generate-lockfiles) --> lockfile_path.lock -- (pants package <target>) --> package.tar.gz

In

<http://requirements.in|requirements.in>

I use loose bounds, and because each of the intermediate step is automated, the final one produced has strict bounds.