Actually, discovered the issue. I was using azure-identity, which currently has an issue with one of it's dependencies, Cryptography. I was able to fix the issue by putting an older version of cryptography (43.0.3) in my requirements.txt

This is the link to the github issue:

https://github.com/Azure/azure-sdk-for-python/issues/38725

In case something happens to the link, here's the answer from one of the cryptography devs explaining what happened:

---------------------------------------------------------------------------
Hi folks, I'm one of the pyca/cryptography developers 😄

This isn't a bug in the pyca/cryptography project. Instead it's a confluence of several factors in the Python and Azure Functions ecosystem interacting in unfortunate ways.

I'm not an Azure user, but Azure Functions appears to have two ways of building Python environments for deployment: local and remote. Remote is recommended for deploying Linux functions because any packages containing native code need to be compatible with the deployment environment and the local host may be a different operating system or even CPU architecture.

However, when you construct an environment on a Linux host and install packages that contain native code and offer precompiled wheels pip will prioritize the highest libc version that's compatible with the underlying distribution of the host. Previously, for glibc-based distributions pyca/cryptography shipped 2.17 (aka manylinux2014) and 2.28 compatible wheels, but with 44 we now ship 2.34 as well.

If the host running the build process (Azure Functions remote build, a GitHub Actions runner, etc) possesses a glibc 2.34 or newer then pip will download the 2.34+ compatible wheel where previously it would have fetched the 2.28+ compatible wheel. This works fine on that host, but when deployed subsequently to Azure Functions the glibc version is older (this comment suggests 2.31), which causes it to fail.

While pinning to 43.0.x is a short term workaround, it is not the correct solution. pyca/cryptography is one of the earlier projects to ship a 2.34 wheel, but usage will only expand in the next year.

Azure has a few possible improvement paths here:

• Improved build process tooling that allows more useful specification of glibc version requirements that can be mapped to manylinux tags. (e.g., I will be deploying in a 2.31 environment so only download wheels compatible with that).

  • This is the best long term path as it can prevent future recurrence of this problem, although it will also require users have some reasonable mechanism to determine what the runtime environment requirements are.

• Updating the Azure Functions runtime environment more often to ensure newer glibc versions are available.

  • This is a good idea anyway, but will only reliably prevent the problem if you ensure you never fall behind the highest version shipped by manylinux. (Side note, these docker images are a convenience function and not required to produce wheels for newer glibc versions, but in practice the entire community uses the manylinux project's images).

• Changing documentation to require passing --platform manylinux_2_17_x86_64 as part of pip invocations.

  • This is a short term fix as all specific glibc manylinux versions are eventually deprecated and removed. If you choose to do this you'll need to both consistently update the documentation and also deal with users reporting failures as older manylinux versions are retired by various projects.