Files
heroku-buildpack-python/builds
Ed Morley fcf696b835 Add support for Heroku-20 (#968)
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@.
2020-10-07 19:44:33 +01:00
..

Python Buildpack Binaries

The binaries for this buildpack are built in Docker containers based on the Heroku stack image.

Configuration

In order to publish binaries AWS credentials must be passed to the build container. If you are testing only the build (ie: bob build), these are optional.

In addition, unless you are building the official binaries for Heroku (which use the defaults specified in each Dockerfile), you will need to override S3_BUCKET and S3_PREFIX to match your own S3 bucket/use case.

If you only need to set AWS credentials, you can do so by setting the environment variables AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY before calling the make commands.

For example:

set +o history # Disable bash history
export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
set -o history # Re-enable bash history
make ...

If you need to override the default S3 bucket, or would prefer not to use credentials via environment variables, then you need to instead use a Docker env file like so:

  1. Copy the builds/dockerenv.default env file to a location outside the buildpack repository.

  2. Edit the new file, adding at a minimum the values for the variables AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY (see Docker env-file documentation).

  3. Pass the path of the file to the make commands using ENV_FILE. For example:

    make ... ENV_FILE=~/.dockerenv.python-buildpack
    

Launching an interactive build environment

To start an interactive version of the build environment (ideal for development) use the buildenv make target, passing in the desired STACK name. For example:

make buildenv STACK=heroku-18

This will create the builder docker image based on the latest image for that stack, and then start a bash shell where you can run bob build, bob deploy, and so forth.

The builds/ directory is bind-mounted into the running container, so local build formula changes will appear there immediately without the need to rebuild the image.

Bulk deploying runtimes

When a new Python version is released, binaries have to be generated for multiple stacks. To automate this, use the deploy-runtimes make target, which will ensure the builder image is up to date, and then run bob deploy for each runtime-stack combination.

The build formula name(s) are passed using RUNTIMES, like so:

make deploy-runtimes RUNTIMES='python-X.Y.Z'

By default this will deploy to all supported stacks (see STACKS in Makefile), but this can be overridden using STACKS:

make deploy-runtimes RUNTIMES='python-X.Y.Z' STACKS='heroku-16 heroku-18'

Multiple runtimes can also be specified (useful for when adding a new stack), like so:

make deploy-runtimes RUNTIMES='python-A.B.C python-X.Y.Z' STACKS='heroku-20'

Note: Both RUNTIMES and STACKS are space delimited.