mirror of
https://github.com/kennethreitz/heroku-buildpack-python.git
synced 2026-06-05 15:00:19 +00:00
Ed Morley
42076f1bf4
The standalone Geo buildpack offers more modern GDAL/GEOS/PROJ library versions, and can be used by apps in all languages, not just Python: https://github.com/heroku/heroku-geo-buildpack As such the Python buildpack's undocumented built-in support was deprecated back in April 2020, with a scheduled removal date of 6th October 2020: https://devcenter.heroku.com/changelog-items/1759 https://help.heroku.com/D5INLB1A/python-s-build_with_geo_libraries-legacy-feature-is-now-deprecated Metrics show very few builds continuing to use the built-in support. Apps with the `BUILD_WITH_GEO_LIBRARIES` env var set will now be shown a warning directing them to the standalone buildpack, as well as apps that hit GDAL related pip install errors but aren't using the env var. This also moves us one step closer to being able to remove the vendored copy of pip-pop (which is partially broken on newer pip). Closes @W-7654424@.
Python Buildpack Install Steps
TODO: Add context on Python install steps, such as why symlinking vs copying
Installing Python packages using Pip
Convention: Use python process to invoke Pip
We don't use this convention (yet) but this is an upcoming change being considered.
This is a bigger concern on Windows than it is in Linux environments, but an emerging convention in the Python community is to invoke pip using:
python3 -m pip [options]
Invoking pip this way ensures correct location - python knows where these packages are stored because it put them there (defaults to Python's pathing info).
All normal command line options are available using this method.