https://pantsbuild.org/ logo
Join Slack
Powered by
using pex==2.0.0 and pants 1.24.0.dev2
# pex
r
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
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
pinning down idna doesn't seem to help
h
Hmmm
r
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
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
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
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
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
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
you mean:
Copy code
python_requirement_library(
  name='requests',
  dependencies=[
    ':idna',
  ],
  requirements=[
    python_requirement(name='requests',
                       requirement='requests'),
  ])
h
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
Open in Slack
PreviousNext
Powered by