I recently updated to Pants 2.4.0 in our project, which uses a constraints file which we update pretty regularly. Previously we were using Pants 2.2.0. With 2.2.0, we were pulling in

setuptools

50.3.2, but with 2.4.0, we're now pulling in

setuptools

53.1.0. However, we're also using the

python_awslambda

packaging type in our codebase, which is based on

lambdex

, which apparently has a

setuptools

constraint of

<50.4,>=50.3.0

, which is unsatisfiable with

setuptools==53.1.0

. I can pin

setuptools

to the old 50.3.2 and still build lambdas, but this was rather unexpected. I see a few old open PRs on the lambdex repository that seem possibly related (such as https://github.com/wickman/lambdex/pull/8). Is this a known issue? Is there a better way to handle such conflicts than what I'm doing? Thanks in advance.

Sorry for this! I encountered it myself recently in the lambdex context. Long-term we should relax that constraint on lambdex when we can, but short term we should be resolving tools like lambdex against a separate constraints file (one per tool) and not against the user constraints file. We plan to work on this ASAP, as it is annoying.

Yeah, it looks like I've got a path forward at the moment. I appreciate the context; the per-tool constraint approach sounds like a winner 👍 Looking forward to it!

Tracked here, BTW: https://github.com/pantsbuild/pants/issues/11898

nice 👍