https://pantsbuild.org/ logo
Join Slack
Powered by
Hey everyone, I’m debugging a strange issue with r...
# general
f
Hey everyone, I’m debugging a strange issue with running a service built with 
python_awslambda
, with this resolver error being raised when the function is invoked:
Copy code
[ERROR] ResolveError: A distribution for orjson could not be resolved in this environment.Found 1 distribution for orjson that do not apply:
1.) The wheel tags for orjson 3.7.1 are cp38-cp38-manylinux_2_28_x86_64 which do not match the supported tags of DistributionTarget(interpreter=PythonInterpreter('/var/lang/bin/python3.8', PythonIdentity('/var/lang/bin/python3.8', 'cp38', 'cp38', 'manylinux_2_26_x86_64', (3, 8, 13)))):
cp38-cp38-manylinux_2_26_x86_64
cp38-cp38-manylinux_2_25_x86_64
cp38-cp38-manylinux_2_24_x86_64
cp38-cp38-manylinux_2_23_x86_64
cp38-cp38-manylinux_2_22_x86_64
cp38-cp38-manylinux_2_21_x86_64
...
Does anyone happen to know what can be done here? Am I to believe that the 
cp38-cp38-manylinux_2_28_x86_64
platform is not compatible with that of the lambda runtime?
After doing some digging (and reading PEP-600 this makes sense, since the lambda runtime has glibc 2.26 which does not play well with the orjson wheel, which has 2.28. I am going to lower our constraint to an older version without an older version being available.
🤞 1
👍 1
It worked 🙂
Would we consider this a bug with the pants lambda integration? In a perfect world we would know what glibc version is available in the runtime but maybe that information isn’t easily available, and moves around as amazon patches things.
In this case specifically there were manylinux2014 that were available as well that might have worked, but the newer glibc version was chosen regardless
h
Good find! Whether it's philosophically a bug or not, it would nice to handle. Could you open a ticket with all the details? https://github.com/pantsbuild/pants/issues/new/choose
👍 1
2 Views
Open in Slack
PreviousNext
Powered by