https://pantsbuild.org/ logo
#pex
Title
# pex
r

rapid-crayon-8232

02/17/2020, 3:21 PM
using pex==2.0.0 and pants 1.24.0.dev2
requests==2.22.0
same when running on macos:
Copy code
Failed to execute PEX file, missing macosx_10_15_x86_64-cp-37-cp37m compatible dependencies for:
idna
requests
apparenlty it's a symptom of pypa/pip#988 (not sure). I think that what's happening is: • I have some other package(s) that requires
idna>2.x
• pip install idna==2.9, that was released 8 hours ago • requests fails because it needs
idna<2.9,>=2.5
h

happy-kitchen-89482

02/18/2020, 4:37 AM
Yeah, that seems like an issue with pip itself
A workaround might be to pin a version of idna in your own requirements.txt
We are working on two things that will help with this sort of thing: 1. Lockfile support in Pants 2. A proper dependency resolver-as-a-service (as a Toolchain product)
r

rapid-crayon-8232

02/18/2020, 11:02 AM
pinning down idna doesn't seem to help
h

happy-kitchen-89482

02/18/2020, 11:12 AM
Hmmm
r

rapid-crayon-8232

02/18/2020, 11:13 AM
A proper dependency resolver-as-a-service (as a Toolchain product)
isn't pip working on the same thing this year? I saw something pass on twitter some time ago.
h

happy-kitchen-89482

02/18/2020, 11:14 AM
Are you depending on that pinned version of idna in your code? You'd need to add a dep on
3rdparty:idna
(or whatever) wherever you have a dep on requests
pip is working on a better resolver algorithm within pip, apparently
Or has declared that they plan to
It will be complicated to do - currently they figure out a requirement's dependencies by actually installing the requirement, so backtracking will be very expensive. I don't know how they plan to handle that.
Our algorithm (which already exists, it's just not finished integrating into a Pants workflow) uses preprocessed dependency data, so it can backtrack cheaply. It generates a lockfile without actually installing anything.
But none of this helps you right now...
r

rapid-crayon-8232

02/18/2020, 11:18 AM
actually some package I'm depending on in one of my libraries depends on requests, and I'm not sure which one haha 😅 , pinning idna in the binary that contains everything fixed it
h

happy-kitchen-89482

02/18/2020, 11:18 AM
Ah perfect - so your binary depends explicitly on your
3rdparty:idna
?
That is not ideal of course, since you don't use idna directly, but it's a good workaround.
r

rapid-crayon-8232

02/18/2020, 11:21 AM
yep not ideal, but at least it's working , I'll try to find the source and pin idna there, but then we'll have to that in every new package that uses requests
Our algorithm (which already exists, it's just not finished integrating into a Pants workflow)...
nice adding it to my pants wishlist: 1- pex v2 in pants 2- lockfiles 3- dep resolver
h

happy-kitchen-89482

02/18/2020, 6:08 PM
We're working on all of these, fortunately
❤️ 2
Re pinning idna, if you have many targets that depend on requests you can make your requests target depend on the pinned idna, so that those many targets don't have to worry about it
I'm guessing you have a
requirements.txt
along side a
python_requirements()
stanza in a BUILD file?
r

rapid-crayon-8232

02/18/2020, 6:11 PM
you mean:
Copy code
python_requirement_library(
  name='requests',
  dependencies=[
    ':idna',
  ],
  requirements=[
    python_requirement(name='requests',
                       requirement='requests'),
  ])
h

happy-kitchen-89482

02/18/2020, 6:11 PM
haha exactly
👍 1
python_requirements()
is just a macro that expands to a bunch of
python_requirement_library
targets
but nothing stops you from having an explicit one instead
Nice