linux wheel missing for 1.1.0

[benpreisler]

Error: PythonPipBuilder:ResolveDependencies - {greenlet==1.1.0(wheel)}

python 3.8.6

1.1.0 is failing to find the wheel on amazonlinux 2 machines

Specifically this is failing for me when building AWS lambdas using https://hub.docker.com/r/lambci/lambda/ which uses amazonlinux:2 https://github.com/lambci/docker-lambda/blob/master/base/base-2/Dockerfile

https://hub.docker.com/_/amazonlinux

1.0.0 works fine on the amazonlinux 2 machine and is pulling this wheel:

Wheel-Version: 1.0
Generator: bdist_wheel (0.36.2)
Root-Is-Purelib: false
Tag: cp38-cp38-manylinux2010_x86_64

Thanks!

[jamadden]

I don't know what to tell you. You can see from the file listing on PyPI that the wheels with the same tag are uploaded for 1.1.0: greenlet-1.1.0-cp38-cp38-manylinux2010_x86_64.whl.

You may find some more information by passing the -v flag to pip install.

My attitude towards binary wheels is that they are a great convenience. I will try to upload them for projects I maintain, but I can't guarantee it — for example, right now we can't create and upload wheels for python 3.10 on certain platforms. Consumers should always be ready to build from source, or host their own package index with their own pre-built wheels.

[benpreisler]

ok looking further - so the problem is that it is finding the wheel but then pip is failing (thus not dropping back to the sdist like normal when not finding the wheel). I created my own image from the amazon image to try and debug but it actually ran fine then... so I don't know. There is something specifically not playing well with greenlet 1.1.0 and the aws lambda (sam) deploy but you can get around it by forcing greenlet=1.1.0 --no-binary=greenlet

thanks

[jamadden]

Wait, you write “ it is finding the wheel but then pip is failing ”. How so? Can you provide the error messages? (Always provide exact error messages in bug reports.)

This doesn’t look like anything to do with greenlet, something lower level, but I do have some experience with, and friends in, that part of python packaging that may prove fruitful.

[benpreisler]

Well my assumption was that it was finding the wheel because if the correct wheel wasn't available pip should fall back to building it from source by default but it appeared not to be doing that from the normal aws logging that I posted above (which granted isn't much):

Error: PythonPipBuilder:ResolveDependencies - {greenlet==1.1.0(wheel)}

However I reran it with debug logging (that I forgot existed) on and it looks like it can't find the wheel and then also doesn't try to build from sdist:

Running workflow 'PythonPipBuilder'
Running PythonPipBuilder:ResolveDependencies
calling pip download -r /tmp/samcli/source/requirements.txt --dest /tmp/samcli/scratch
Full dependency closure: {greenlet==1.1.0(wheel)}
initial compatible: set()
initial incompatible: {greenlet==1.1.0(wheel)}
Downloading missing wheels: {greenlet==1.1.0(wheel)}
calling pip download --only-binary=:all: --no-deps --platform manylinux2014_x86_64 --implementation cp --abi cp38 --dest /tmp/samcli/scratch greenlet==1.1.0
compatible wheels after second download pass: set()
Build missing wheels from sdists (C compiling True): set()
compatible after building wheels (no C compiling): set()
Build missing wheels from sdists (C compiling False): set()
compatible after building wheels (C compiling): set()
Final compatible: set()
Final incompatible: {greenlet==1.1.0(wheel)}
Final missing wheels: {greenlet==1.1.0(wheel)}
PythonPipBuilder:ResolveDependencies failed
Traceback (most recent call last):
  File "/usr/local/opt/sam-cli/lib/python3.8/site-packages/aws_lambda_builders/workflows/python_pip/actions.py", line 39, in execute
    package_builder.build_dependencies(
  File "/usr/local/opt/sam-cli/lib/python3.8/site-packages/aws_lambda_builders/workflows/python_pip/packager.py", line 137, in build_dependencies
    self._dependency_builder.build_site_packages(requirements_path, artifacts_dir_path, scratch_dir_path)
  File "/usr/local/opt/sam-cli/lib/python3.8/site-packages/aws_lambda_builders/workflows/python_pip/packager.py", line 207, in build_site_packages
    raise MissingDependencyError(packages_without_wheels)
aws_lambda_builders.workflows.python_pip.packager.MissingDependencyError: {greenlet==1.1.0(wheel)}

So AWS bug? It's weird that it only effects greenlet 1.1.0 but also weird that it does work when I try to run it in my own derivative container

I'm submitting an issue to AWS as well and I'll post back here if it ends up being something on their end

[mvanbaak]

Only weird thing I see:

It's using --platform manylinux2014_x86_64

The 2014 files have a filename that does not match the other manylinux variants:
greenlet-1.1.0-cp38-cp38-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (164.6 kB)

Personally I have no idea how all this works with the manylinux itc, but it looked off to me?

[mvanbaak]

I'm submitting an issue to AWS as well and I'll post back here if it ends up being something on their end

Can you share the AWS issue here?

I'm running into the same problem...

[jamadden]

PyPI doesn't allow uploading of invalid manylinux tags, so that should be a valid name. It's produced by the official PyPA manylinux docker images and the official 'auditwheel' tool. Also, there are wheels uploaded for several different manylinux versions, going all the way back to manylinux1. pip should investigate all the options and choose the best one matching the current system; something in the way the install is being done is short-circuiting that process here, but that's out of greenlet's control.

[mvanbaak]

Thanks for your time to explain this. Like I said, I had no idea what it all was. Now at least I know a little.
Keep up the good work and lets hope AWS comes with with some fix.

[benpreisler]

I can't post the AWS issue since it's not in the public support system - I'll update info about it here though

Hey,
What's the best way to fix this issue with a package using greenlet? I don't import or use greenlet myself, but sqlalchemy or a different package does. Could the fix above be applied aswell? If so, how?

EDIT: For now I just reverted to an older version of SQLAlchemy.

[benpreisler]

yeah actually that is how we are using greenlet - via sqlalchemy

if you include it in your requirements file directly and force it to bypass the wheel:
greenlet=1.1.0 --no-binary=greenlet
it will work with latest sqlalchemy

[benpreisler]

AWS fixed this now:
aws/aws-lambda-builders#234

I can confirm this works with latest sam cli 1.24.1