Previously the buildpack's S3 bucket was defined in two places - once
in `VENDOR_URL` and again during the pip installation step. This
duplication was necessary since `VENDOR_URL` also contained the stack's
name, whereas the pip use-case used a non-stack-specific S3 key prefix.
In order to:
* reduce this duplication
* simplify this buildpack's S3 bucket migration (where we'll soon be
needing the vary the bucket name and wouldn't want to have to
duplicate that logic in multiple places)
* allow overriding of the URL for the pip use-case
...the `VENDOR_URL` variable has been replaced with `S3_BASE_URL` which
no longer contains the stack name.
The user-configurable override has similarly been renamed from
`BUILDPACK_VENDOR_URL` to `BUILDPACK_S3_BASE_URL`. Note: As before,
this override cannot be set via standard app variables (see #989).
The unused `USE_STAGING_BINARIES` environment variable has been
removed, since it's a leftover from the project to stand up a staging S3 bucket.
It's redundant given the `BUILDPACK_S3_BASE_URL` variable.
Closes @W-8142401@.
Set GDAL and GEOS library locaiton explicitly in environment
variables:
* GDAL_LIBRARY_PATH "/app/.heroku/vendor/lib/libgdal.so"
* GEOS_LIBRARY_PATH "/app/.heroku/vendor/lib/libgeos_c.so"
Django has to settings with the same name. The setup now works as
described here:
https://devcenter.heroku.com/articles/postgis#geodjango-setup
* only do this on heroku-16
* history
Signed-off-by: Kenneth Reitz <me@kennethreitz.org>
* code comment
Signed-off-by: Kenneth Reitz <me@kennethreitz.org>
Since if someone previously had `GDAL` in their requirements file, they
would already have the gdalserver binary present from `bin/steps/gdal`
but be missing the proj and geos vendor files. By checking for `proj`
instead, we ensure that the vendoring isn't incorrectly skipped in this
case.
Ed Morley
kennethreitz