mirror of
https://github.com/kennethreitz/heroku-buildpack-python.git
synced 2026-06-05 23:10:16 +00:00
Ed Morley
fcf696b835
This adds support for the upcoming Heroku-20 stack. The Heroku-20 Dockerfile is identical to that for Heroku-18, other than the base image, and stack-related env var changes. The initial Python versions made available will be those in: https://devcenter.heroku.com/articles/python-support#supported-runtimes https://devcenter.heroku.com/articles/python-support#supported-pypy-runtimes ...minus CPython 2.7, since it's EOL. Which are: * `python-3.6.12` * `python-3.7.9` * `python-3.8.6` * `python-3.9.0` * `pypy2.7-7.3.2` * `pypy3.6-7.3.2` Note: Unlike CPython 2.7, the PyPy 2.7 branch is still supported: https://doc.pypy.org/en/latest/faq.html#how-long-will-pypy-support-python2 In addition, I've generated binaries for each patch release immediately prior to the latest versions (with the exception of 3.9.0, since there isn't one), otherwise it's not possible to run the "out of date Python" warning tests. The binaries were generated using the process here: https://github.com/heroku/heroku-buildpack-python/blob/main/builds/README.md Specifically: ``` make deploy-runtimes STACKS='heroku-20' \ RUNTIMES='python-3.6.11 python-3.6.12 python-3.7.8 python-3.7.9 python-3.8.5 python-3.8.6 python-3.9.0 pypy2.7-7.3.1 pypy2.7-7.3.2 pypy3.6-7.3.1 pypy3.6-7.3.2' \ ENV_FILE=... ``` Binaries for the GDAL/GEOS/PROJ feature have not been generated, since it's deprecated and due for removal shortly: https://help.heroku.com/D5INLB1A/python-s-build_with_geo_libraries-legacy-feature-is-now-deprecated Note: Like the Python 3.9.0 release, this uses the new S3 bucket, so apps will need to be using a recent version of the buildpack in order to build on Heroku-20: https://devcenter.heroku.com/articles/python-support#checking-the-python-buildpack-version Closes @W-7485877@.
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.