The installed pip version check is susceptible to false negatives

[edmorley]

As part of the Python step step, the pip version is checked here:

heroku-buildpack-python/bin/steps/python

Line 151 in 156b07c

if [ "$FRESH_PYTHON" ] || [[ ! $(pip --version) == *$PIP_UPDATE* ]]; then

pip --version outputs stdout of form:

$ pip --version
pip 20.1.1 from /usr/local/lib/python3.8/site-packages/pip (python 3.8)

And $PIP_UPDATE is set to a pip version string such as 20.0.2:

heroku-buildpack-python/bin/compile

Line 67 in 156b07c

PIP_UPDATE="20.0.2"

The way the version check conditional is currently written means that the check will succeed if $PIP_UPDATE happens to be a substring of the real pip version, even if the version is not an exact match.

If pip always used a versioning scheme of X.Y.Z this would not be a problem, however for new minor version releases pip uses versions of form X.Y instead of X.Y.0 (ie: 20.1 instead of 20.1.0). This means that some release versions are a substring of another version (20.1 is a substring of 20.1.1).

As such, if we were ever to downgrade PIP_UPDATE from say 20.1.1. to 20.1 in response to a regression (or if an app rolled back to a previous buildpack release that used the older version), then the pip version would be seen as matching, and not trigger a downgrade as expected.

We should either:

1. Use something like *" $PIP_UPDATE "* (with spaces padding) instead of *$PIP_UPDATE*
2. Switch to a way of fetching the pip version that doesn't require matching substrings (eg python -c 'from pip import __version__; print(__version__)')
3. Let pip decide whether it's up to date itself, by just unconditionally calling get-pip.py with the target pip version

[edmorley]

In #1007 I went with:

3. Let pip decide whether it's up to date itself, by just unconditionally calling get-pip.py the pip wheel with the target pip version