# general


07/15/2022, 2:34 AM
I'm trying to package an AWS lambda on macOS, and happen to depend transitively on, 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 (
) so is kinda relevant to be including in a lambda. This gives an error:
Copy code
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:
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"]}, ...
python_awslambda(dependencies=["!backend#future"], ...)
, but these had no effect, presumably because they're operating outside pex
Ah, it seems the latest version of aws_xray_sdk doesn't depend on future, so I can see if upgrading works... but I'd be interested in the answer here in case it comes up again. 😄
👍 1


07/15/2022, 6:55 PM
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 the best you could do is fork the requirement and change its metadata


07/15/2022, 10:52 PM
Yeah, upgrading worked well enough, hopefully we don't hit any similar cases in future 😅 thanks for the confirmation
❤️ 1