nice-florist-55958
07/15/2022, 5:10 PMpackage
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?witty-crayon-22786
07/15/2022, 5:32 PMWhat happens when youaapackage
owningpython_distribution
with a parametrized resolve field? Which requirement will it use inpython_sources
?install_requires
python_distribution
doesn’t have a resolve
, so you’d have to explicitly choose one resolve or the other to depend onnice-florist-55958
07/15/2022, 5:46 PMinstall_requires
in the auto setup.py
?witty-crayon-22786
07/15/2022, 5:47 PMpython_distribution
and pex_binary
, the lockfile should make that a non-issue right? it’s safe to use a range that describes what you think you are compatible with, but a deployment of the app will use some exact set of versions from that rangegenerate-lockfiles
will generally only be run when ranges have changed or new versions have been added, so it should be relatively stable.generate-lockfiles
to cause some unnecessary churn when adding new deps.nice-florist-55958
07/15/2022, 5:57 PMwitty-crayon-22786
07/15/2022, 5:58 PMpython_distribution
… not sure there.)nice-florist-55958
07/15/2022, 6:02 PMpandas~=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.pandas
example.witty-crayon-22786
07/15/2022, 6:04 PMnice-florist-55958
07/15/2022, 7:26 PMhundreds-father-404
07/15/2022, 7:27 PM