mirror of
https://github.com/kennethreitz/heroku-buildpack-python.git
synced 2026-06-05 23:10:16 +00:00
Ed Morley
31e8f48db8
Since: * we'll be updating setuptools soon, and newer setuptools has dropped support for Python versions this buildpack needs to support. As such if we continued to vendor setuptools, we would need to vendor at least three different versions. * we want to try and update setuptools more frequently than we have in the past, which will mean more repo bloat from binary churn. * we're still pinning to a specific version, meaning vendoring doesn't have determinism benefits. * setuptools is only fetched from PyPI for new installs (or where versions have changed), so this doesn't increase build time, load on PyPI, or reliance on PyPI in the common case. * setuptools is already being inadvertently installed from PyPI prior to being installed from the vendored copy (see #1001), so we're in effect already using/depending on PyPI here. * switching to storing setuptools on S3 wouldn't help reliability as much as it would appear at first glance, since the later `pip install` of customer dependencies will fail if PyPI is down anyway.
Python Buildpack Install Steps
TODO: Add context on Python install steps, such as why symlinking vs copying
Installing the Pip tool
The Python Buildpack uses a tool called get-pip to install the pip tool. This
is done in the python script.
This is in part because Python historically did not come with pip by default.
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.