mirror of
https://github.com/kennethreitz/heroku-buildpack-python.git
synced 2026-06-05 23:10:16 +00:00
b74a41395e
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@.
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.