I'm trying to package an AWS lambda on macOS, and happen to depend transitively on https://pypi.org/project/future/0.18.2/#files, which seems to be a pure-Python package that's only provided in sdist form, no wheels. Extra unfortunately, this dependency is from one of AWS's SDK libraries (

aws_xray_sdk

) so is kinda relevant to be including in a lambda. This gives an error:

Dependency on future not satisfied, 1 incompatible candidate found:
1.) future 0.18.2 (via: aws-lambda-powertools==1.25.10; python_full_version >= "3.6.2" and python_full_version < "4.0.0" -> aws-xray-sdk<3.0.0,>=2.8.0 -> future) does not have any compatible artifacts:
    <https://files.pythonhosted.org/packages/45/0b/38b06fd9b92dc2b68d58b75f900e97884c45bedd2ff83203d933cf5851c9/future-0.18.2.tar.gz>

I suspect our particular app doesn't actually need this package at runtime: 1. Is it possible to tell pex/`python_awslambda` that this specific sdist is okay? I'm assuming that it is okay, since it's pure Python... 2. Alternatively, can we break the dependency? I tried adding various overrides, like

python_requirements(overrides={"aws_xray_sdk": {"dependencies": ["backend#setuptools", "!backend#future"]}, ...

and

python_awslambda(dependencies=["!backend#future"], ...)

, but these had no effect, presumably because they're operating outside pex

did that work out? you're right on both questions. 1) no, every wheel unfortunately must be prebuilt 2) indeed, the dependency is being loaded via pip itself by inspecting the metadata of the requirement, e.g. pyproject.toml or setup.py. the best you could do is fork the requirement and change its metadata

Yeah, upgrading worked well enough, hopefully we don't hit any similar cases in future 😅 thanks for the confirmation