What happens when you

package

a

python_distribution

owning

python_sources

with a parametrized resolve field? Which requirement will it use in

install_requires

? Is there any way to take advantage of automatic

setup.py

generation but override

install_requires

with looser constraints than what's expressed in the resolve's input requirements? Right now we have pinned constraints for input requirements to the

python-default

resolve, but that is causing our packages to be published with overly strict constraints and generally substantially increasing the likelihood for consumers running into resolve errors in their own environments/apps. Is there any guidance on how to handle the general trade-off between

pex_binary

wanting pinned constraints for the top-level input requirements and

python_distribution

wanting loose constraints? If our input

requirements.txt

to

python_requirements

for

python-default

has pinned constraints, then

python_distribution

s will have pinned

install_requires

in their

setup.py

. But if the constraints are loose, the resolved dependencies could change any time the

generate-lockfiles

is re-ran, thus potentially breaking an app. We'd like to say the

pex_binary

is participating in

python-default-pinned

and the

python_distribution

's

python_sources

are participating in

python-default-loose

, then have Pants infer the two are compatible when the stricter one is in play. Is there a general idea of resolve compatibility?

What happens when you

package

a

python_distribution

owning

python_sources

with a parametrized resolve field? Which requirement will it use in

install_requires

?

a

python_distribution

doesn’t have a

resolve

, so you’d have to explicitly choose one resolve or the other to depend on

True, but I mean what will it do for

install_requires

in the auto

setup.py

?

the resolve shouldn’t impact that… it will continue to be the declared range, as you mentioned

But let's say you add a new requirement and have loose constraints for the pre-existing ones. The lockfile gets regenerated and now all the app owners using that resolve have to deal with potentially new versions of dependencies unrelated to the addition/upgrade, but that they depend on and that might now have new versions out that Pants uses. With pinned versions, upgrading a pre-existing dependency can be pre-announced/planned. Edit: You just pointed that out in your last reply.

yea.

It's not even about the transitive dependency at this point in my mind. If

pandas~=1.0

is there, and right now its locked to

1.2.1

, but then a month later someone adds

pyfolio

to the list triggering a regen,

pandas

could get upgraded to

1.3

if it came out in that time period. This could be unexpected. It's hard to have broad constraints across the repo w/ a mix of lib/app code w/o a looser concept of a resolve I think.

sure. aside from the lockfile stability aspect of this though, this does get into a general area of concern for monorepos: code needs tests to ensure its guarantees.

Regarding the python requirement on for python_distributoin. What I had in mind was what we were talking about in the other thread, when another resolve is in play, the explicit requirement gets remapped to another requirement automatically. But I guess no resolve is in play for packaging a python_dist so it will always be the one specifically addressed.

(haven't read this thread yet, catching up from OOO all week) FYI this is the thread where Benjy and I thought through multiple resolve and python_distribution https://github.com/pantsbuild/pants/issues/14322