Install setuptools from PyPI rather than a vendored copy (#1007)

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.

Author: edmorley

CHANGELOG.md

@@ -3,6 +3,7 @@
 # Master
 
 - Output the installed version of pip and setuptools in the build log (#1007).
+- Install setuptools from PyPI rather than a vendored copy (#1007).
 - Reduce the number of environment variables exposed to `bin/{pre,post}_compile` and other subprocesses (#1011)
 
 # 173 (2020-07-21)

bin/steps/python

@@ -170,7 +170,7 @@ if [ "$FRESH_PYTHON" ] || [[ ! $(pip --version) == *${PIP_VERSION}* ]]; then
   rm -fr /app/.heroku/python/lib/python*/site-packages/setuptools-*
 
   /app/.heroku/python/bin/python "$GETPIP_PY" pip=="${PIP_VERSION}" &> /dev/null
-  /app/.heroku/python/bin/pip install "$ROOT_DIR/vendor/setuptools-${SETUPTOOLS_VERSION}-py2.py3-none-any.whl" &> /dev/null
+  /app/.heroku/python/bin/pip install "setuptools==${SETUPTOOLS_VERSION}" &> /dev/null
 fi
 
 set -e