I recently updated to Pants 2.4.0 in our project, ...
# general
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
50.3.2, but with 2.4.0, we're now pulling in
53.1.0. However, we're also using the
packaging type in our codebase, which is based on
, which apparently has a
constraint of
, which is unsatisfiable with
. I can pin
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.
By which I mean that the "short term" solution (per-tool constraints files) is the right long-term thing as well.
The user should not have to take tools into consideration when constructing their constraints.txt!
Apologies for the inconvenience. Sounds like you have a workaround for now?
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!
💯 1
nice 👍