manual override of pip version for pipenv users (PR)

[vityas]

Allow for a manual override of pip version for pipenv users (PR)
#1093

[edmorley]

Hi! Thank you for the PR. I can empathise that being stuck on an old version of Pip if using Pipenv with this buildpack must be frustrating.

However I think it would be better to upgrade pipenv in this buildpack and then be able to remove this pipenv-pip-version special-casing entirely.

Allowing the pip version to be overridden opens the door for a whole lot of pain, since there is very tight integration between the buildpack and pip, meaning that even things like pip removing support for a particular CLI argument has the potential to cause breakage. (Or conversely, pip adds support for something new, the buildpack updates to that pip and starts using the new feature flag, only to have some apps break since the pip version they set N years ago doesn't support it.) This would result in an increase in support tickets, that are often hard to debug and time consuming.

I'd recommend:

1. Short term: Removing the 9.0.2 specification from a custom branch that you use on your apps (one of the reasons the buildpacks are open source is so that people can fork them if desired)
2. Medum/longer term: Exploring upgrading pipenv (I know this was ruled out in the past, but that was before the change of language owners, and I'm more open to the idea)

(Also, whatever approach is picked we always need tests with a change - in particular tests would have caught the fact that this PR doesn't currently work)

Anyway sorry not to have the answer you were hoping for - happy to chat more about this if you have any questions :-)

[edmorley]

Unfortunately this won't work, since $PIP_VERSION_OVERRIDE will never be set here, since app-provided env vars are passed in via $ENV_DIR.

[edmorley]

Hi! The pipenv version has just been updated in #1169. Some more context on that can be found here:
#987 (comment)

Thank you again for the PR, however supporting custom pipenv/pip versions is something that I believe will introduce more issues than it fixes for the reasons mentioned above (#1094 (review)), so I won't be able to merge this.

To give a more concrete example of the types of problems we will encounter...

Imagine a user sets a custom version on their only (production) app, and a few months/years later start using a staging app, review apps or Heroku CI. They forgot they added the custom env var, so didn't set it on the staging app and/or apps.json config. This works fine initially, so long as the buildpack's default version (and CLI flags used) are compatible with their custom version. Later on the buildpack changes pip/pipenv version and/or CLI flags used, causing builds break in one of their environments but not the other. This is confusing for them to debug (and they may not be inclined to debug, particularly since nothing changed on their side) - so they open a support ticket saying "we haven't changed anything on our app for a while, the breakage must be something Heroku has done, please fix it". Now only 0.1% of customers may hit this case, however at cloud-scale this means days/weeks of numerous support tickets.

Another issue is test matrix permutations. As-is the test suite has to test multiple Heroku stacks, versions of Python, different package manages, etc. If we add support for say configuring pip and pipenv versions there are immediately 3 more permutations (both set to custom, only pipenv set to custom, only pip set to custom), even before we potentially test a handful of different pipenv/pip versions that customers might be using.

The best approach here is for the buildpack to stay more up to date with pipenv versions, and then the need for customising version goes away.

Anyway hope that helps give some more context :-)