python-buildpack: python3.8.12 - fatal error: Python.h: No such file or directory

We are able to reproduce the underlying issue a few different ways, and we have a fix for the root case on the develop branch.

You can try this out by using the develop branch while pushing your app:

cf push <args> -b https://github.com/cloudfoundry/python-buildpack#develop

Please try this out and let us know if it works (or doesn’t work).

We expect to release a new version of the buildpack shortly, but any feedback before then would be welcome.

Like @Deviaruna said, this issue seems to be caused by a setuptools version downloaded as a transitive dependency by users’ direct dependencies (e.g. psycopg2), and not due to a dependency provided by the buildpack. For the same app, I can see this same issue occurring while using an older version. I’m not sure buildpacks have control over it though I can look into it if there’s something we can do.

@sunny-repo88 For https://github.com/sunny-repo88/cf-python-buildpack-withoutapt, this works for me:

--- a/requirements.txt
+++ b/requirements.txt
@@ -1,3 +1,4 @@
 Flask==2.0.1
 gunicorn==20.1.0
+setuptools==65.1.1
 psycopg2==2.9.1

Edit: fix link

Confirmed. Issue resolved in https://github.com/cloudfoundry/python-buildpack/releases/tag/v1.7.58.

Thanks to the team!

I can confirm that xmlsec now compiles correctly using the repro steps above. Thanks for the quick fix!

@mrogaski @amhuber yes, agreed. We believe that when an application depends on a project that uses PEP-517 Build Isoloation - like krb5 has done since its creation - and that project has a build-dependency on setuptools without an upper limit (like krb5) then the latest version of setuptools (i.e. 65.2.0) is downloaded and we observe the same issue as if the app had setuptools as a direct dependency.

We are actively exploring a fix for the root cause - setuptools >= 65.2.0 not working with the python buildpack - as well as any potential workarounds to assist with pinning the version of setuptools when it is pulled in as a transitive dependency. We will keep this thread updated with our investigation.

Keeping setuptools permanently pinned to an old version isn’t going to work forever. I’m hoping there are some updates that can be made to the buildpack to adjust to whatever setuptools is expecting. It looks like https://github.com/heroku/heroku-buildpack-python/commit/b2dfe7397bf2f57b70799954277dd01a9c034432 might be related.

Hi All, We were facing the same issue in multiple projects. One of our colleague has figured out the reason behind the crash. One transient package upgraded i.e. setuptools from 65.1 to 65.2 version. If you could downgrade setuptools to 65.1.0, that would work. Thanks

I face the same issue. I use Python 3.8.10 & psycopg2 2.9.3 and “changed nothing” since 8th Aug.

@arjun024 , thanks for quick response. I have another example without using apt buildpack

Steps to reproduce:

git clone https://github.com/sunny-repo88/cf-python-buildpack-withoutapt
cd cf-python-buildpack-withoutapt ;cf push

Behaviour:

Able to install psycopg2 in python 3.6.15
Unable to install psycopg2 in python 3.8.12 with error log below

We are able to install both example in fresh new docker environment - python:3.8-buster

We are also seeing this on our environments. We haven’t figured out what changed yet, but apps that were previously deploying are now getting this error, and the apt.yml packages were set up correctly to support compilation of xmlsec.