https://pantsbuild.org/ logo
Join Slack
Powered by
hey, another question, we seem to be hitting this ...
# general
h
hey, another question, we seem to be hitting this occasional error on some of our targets when upgrading to at least >=2.1.0
Copy code
Failed to resolve compatible distributions:
1: boto3==1.10.7 requires botocore<1.14.0,>=1.13.7 but botocore 1.19.25 was resolved
I think the target under question has a direct dep on PyAthena==1.10.0 which transitively has a dep on 
botocore>=1.5.52
and it seems that this unbounded dep is finding botocore 1.19.25 before resolving the bounded dep 
botocore<1.14.0,>=1.13.7
from 
boto3==1.10.7
Is there anyway to work around this?
s
Have you implemented constraints?
h
no
s
Start there. Implement constraints and set the botocore version to the required version for your application
h
ok, thanks, as i read through it, this appears to be a global thing, we run a per-project monorepo with discouraged/limited cross-project imports. in an ideal world we would have a constraints per project i think. i’ll give it a go tho
s
Oh trust me… I am in the same boat with the mono-repo. I hope they implement per package or module constraints at some point. would make my life so much easier
h
we also have a mix of py2/py3. would be nice to be able to have separate constraints per interpreter
🔥 1
s
yeah that would be helpful. I would like to see the ability to do constraints within the BUILD file. That way one off projects such as SAM or lambda projects could have seperate constraints
w
multiple constraints/lockfiles per repository was one of the top voted issues in the recent prioritization, so we’ll have more info on that soon! hopefully next week.
🔥 2
h
but that did seem to do the trick, thanks!
👍 1
w
there is a doc linked from https://github.com/pantsbuild/pants/issues/11165 with more info on the multi-lockfile/resolve problem: if you have any feedback, it would be appreciated!
s
@witty-crayon-22786 I will take a look
h
yep, looking now
i’d just like to say that this issue seems like a regression. i know that pex significantly changed in v2 but constraints.txt seems kind of like a hack. if i have a direct dependency on foo==1.0 which transitively depends upon bar>=1.0 and then I have another direct dependency on bar==1.0. Pants (or pex) should be able to correctly identify that the set of bar packages that conform to this is bar>=1.0,<=1.0 or just more simply bar==1.0. I feel like this is the same bug we ran into with pex 1.x when it would throw AmbiguousResolvable and which I submitted a PR for in: https://github.com/pantsbuild/pex/issues/366
w
so, two different 2.0 launches happened in this case:
pex moved to 2.0 a few months ago, and the headline feature was switching to PIP as its resolver, for better consistency with the rest of the ecosystem
pants 1.26 (iirc) was the first to use pex 2.0
the downside of a move to PIP is that … PIP didn’t actually contain a “resolver” until… sometime in the last few weeks (https://twitter.com/pradyunsg/status/1333399403051311104)
h
yah, i think that we hit this because we’re jumping from 1.25 to 2.1 so that includes the jump to pex2
well that’s good news
switching to pip seems like the best course of action i agree. will pex be updating to this latest pip anytime soon?
w
but yea: sorry for the trouble here, especially since you contributed to pex
it will, yea. i expect that the new resolver will be behind a flag for a while though.
h
it’s not a problem, i understand the reasons to want to use pip for better consistency. will make pex maintenance much easier i imagine
2 Views
Open in Slack
PreviousNext
Powered by