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/1759https://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@.
Since the stack is end of life and builds have been disabled:
https://devcenter.heroku.com/changelog-items/1943
There are only two temporarily exempted customers using Python, who
can switch to the Cedar-14 support branch if they still need to build
their Python apps (most of which haven't been built recently).
Closes @W-8054727@.
Since:
* We want the S3 bucket to be owned by a different AWS account and it's
not possible to transfer ownership of an existing bucket.
* In the future we want to rebuild some of the Python runtime archives
(for example to improve the sqlite3 handling, or to tweak the compile
flags used), and it will be easier to reason about the change if we
can guarantee only recent buildpack versions are using the assets
rather than several year old unmaintained forks.
The assets were synced from the old bucket using (minus the `--dryrun`):
```
aws s3 sync s3://lang-python s3://heroku-buildpack-python \
--dryrun \
--metadata-directive REPLACE \
--exclude "*" \
--include 'common/*' \
--include 'heroku-*/runtimes/*' \
--include 'heroku-*/libraries/vendor/gdal.tar.gz' \
--include 'heroku-*/libraries/vendor/geos.tar.gz' \
--include 'heroku-*/libraries/vendor/proj.tar.gz' \
--exclude 'common/pip-20.0.2-py2.py3-none-any.whl' \
--exclude '*/runtimes/*-opt.tar.gz' \
--exclude '*/runtimes/sqlite-free/*'
```
The files that were `--exclude`d are those that are no longer used,
or test assets that were not officially released.
The Cedar-14 assets were not migrated since it's EOL next month.
The old S3 bucket will be left untouched for the foreseeable future
(ie: we won't be deleting it), since builds using older versions of this
buildpack (either due to pinning to a tag or via a fork) will still be
using assets from it.
Closes @W-8060097@.
* Moves all manual build steps to make targets, to simplify
the commands run, and reduce chance for error.
* Removes the need to remember to rebuild the builder
image by building it automatically prior to launching.
* Adds a new make target for deploying multiple runtime
versions at once to speed up the common case.
* Reduces repetition/superfluous content in documentation.
* Removes unused `S3_REGION` from `dockerenv.default`
(the contents of S3 buckets inherit the region of the bucket).
* Documents build dependencies in `requirements.txt`.
Closes @W-8119717@.
[skip changelog]
* Switches from using Python 2 to Python 3 for `bob-builder`
* Adds `--no-install-recommends` to reduce unnecessary packages
* Removes unnecessary pinning of pip for Heroku-18 build
* Moves `DEBIAN_FRONTEND` to RUN level env var, given:
https://serverfault.com/a/797318
Refs @W-8119717@.
[skip changelog]
The existing Python 3.4.10 archive actually contained Python 3.7.2,
since the version in the source URL was not updated when the file was
created in #813.
The build formula now uses the shared build script approach like all of
the other build scripts, which ensures the version can never get out of
sync (since it's extracted from the formula filename).
The build for Heroku-18 failed to compile `_ssl` properly (even though
the build exited zero) since Python 3.4.10 is old enough it doesn't work
well with libssl1.1. Installing `libssl1.0-dev` in the build image
locally resolved the issue - however we don't want to use that in the
future for newer Python, so I've not updated the `heroku-18.Dockerfile`.
In addition, with the rebuilt archives the tests now pass on Cedar-14,
so no longer need to be marked as failing.
Closes @W-7947035@.
Adds support for:
* CPython 2.7.18, 3.5.9, 3.7.7 and 3.8.3
* PyPy 2.7 and 3.6, version 7.3.1
The binaries will need generating and uploading before CI will pass.
Note: Whilst the build script for CPython 3.8.3 did already exist in the
repository, it appears to have been accidentally created in #920, which
predated the existence of that version of Python - so the binaries do
not exist on S3.
The Heroku-18 Docker image tag has also been unpinned, since the new
libssl version is now available at runtime in all environments, so we
don't need to force building against the older version of the headers.
Fixes W-7582174.
The compile-time cryptography step that used to use the libffi archives
on S3 was removed in 2018:
https://github.com/heroku/heroku-buildpack-python/commit/c373e80c1285260e5adcbc855f54bbeb6999005c
...since the `cryptography` Python package now ships wheels.
The script is also incorrect, since similar to #964 it only skips builds
for Heroku-16, whereas all stacks since Cedar-14 include libffi-dev in
the build image, so don't need it built/uploaded for later vendoring.
Refs W-7485877.
The `libmemcached` package is available in the base stack image for all
stacks newer than `cedar-14`, so at buildpack compile time the vendor
step is skipped for those stacks:
https://github.com/heroku/heroku-buildpack-python/blob/106f2997fa124852a2a35ee8bfa604ad20c47988/bin/steps/pylibmc#L12-L15
As such, it is not necessary to run the libmemcached bob-builder formula
on newer stacks. The conditional has been updated so it correctly handles
heroku-18 and also the upcoming heroku-20.
An exit code of 1 has been used, otherwise `bob upload` will build and
then upload a zero byte archive to S3, which will go unused.
(This is in comparison to bob formulas that are nested, where an exit
code of 0 is actually desirable, since it allows skipping steps.)
Refs W-7485877.
Co-authored-by: Joe Kutner <jpkutner@gmail.com>
Ed Morley