-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix sqlite #858
Fix sqlite #858
Conversation
…SQLite3 steps from runtime build scripts
So right now this won't allow To achieve that, we need to, roughly, do this:
This will ensure that the libsqlite3 headers, as well as a symlink for the generic Then, in
This should then allow building e.g. a |
Capturing for future reference: The reason for the shift in approach is that the apt-buildpack won't load headers properly given the package is still on the platform and ONLY the sqlite headers are not, and thus would not allow users of pysqlite or other utilities to use sqlite on runtime. We're opting to preserve this functionality instead, with added complexity as the tradeoff 🎉 |
Also important: the |
dm.xmlsec.binding, which comes as a dep for python-saml, does not compile on Heroku, using this buildpack, because apparently /usr/include is not available at that time. After some research, it seems that is known behavior and the reason why workarounds for some packages (e.g.sqlite [1]) exist. Hence it may be easiest to simply do something very similiar for libxmlsec1, hopefully without breaking anything else. [1] heroku#858
Rebased from #812 for further work + upstreaming - see other pr for full context on approach