Pipenv install is skipped in cases where it's not safe to do so

[edmorley]

Currently the buildpack skips re-running pipenv install for repeat builds iff (a) the SHA256 of the Pipfile.lock file has not changed since the last successful build, and (b) the Pipfile.lock file does not contain git references:

heroku-buildpack-python/bin/steps/pipenv

Lines 9 to 22 in d1ca05a

	if [[ -f Pipfile.lock ]]; then
	if [[ -f .heroku/python/Pipfile.lock.sha256 ]]; then
	if [[ $(openssl dgst -sha256 Pipfile.lock) == $(cat .heroku/python/Pipfile.lock.sha256) ]]; then
	# Don't skip installation if there are git deps.
	if ! grep -q 'git' Pipfile.lock; then
	echo "Skipping installation, as Pipfile.lock hasn't changed since last deploy." | indent
	mcount "tool.pipenv"
	export SKIP_PIPENV_INSTALL=1
	export SKIP_PIP_INSTALL=1
	fi
	fi
	fi
	fi

However, there are other cases where pipenv install still needs to be run.

For example, imagine a Pipfile containing:

[packages]
mypackage = {file = "packages/mypackage", editable = false}

Since editable = false the local package will be copied into site-packages on the initial build (rather than the original source linked via a .pth file, as happens for editable installs). And then on subsequent builds if no other changes have been made to Pipfile.lock, the pipenv install step will be skipped, even though changes could have been made to files under packages/mypackage/.

(Note: The above is assuming a Pipenv version is being used that is not affected by the regression pypa/pipenv#6054, since otherwise the install will be editable regardless of editable = false)

Whilst we could add "editable" as another property to check within the Pipfile.lock file:

• it would be just as fragile as the current git check unless we resort to properly parsing the file (xref pipenv cache is skipped when it should not be #1398)
• we would have to handle the "editable property isn't specified" case, which means having to hardcode what pipenv's default is for it, that can then get out of sync with pipenv's actual behaviour (and pipenv's behaviour has actually changed on that front, xref As of v2023.8.19 local file dependencies default to being installed as editable pypa/pipenv#6054)
• there may also be other cases where it's not safe to assume pipenv install is a no-op (either currently, or in the future as pipenv evolves)

Ultimately, any optimisation strategy here requires us to make assumptions about pipenv implementation details, and hardcode some of those details in the buildpack, which isn't ideal.

As such, I think we should instead always run pipenv install, and defer to pipenv itself to make the determination as to whether any changes are required. Pipenv install should not take too long to run if there are no changes required (and if it does, that's an upstream bug that pipenv should fix, and not something we should hack around and risk environment correctness issues).

GUS-W-14762837.