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 https://github.com/pypa/pipenv/issues/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 #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 https://github.com/pypa/pipenv/issues/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).
Currently the buildpack skips re-running
pipenv installfor repeat builds iff (a) the SHA256 of thePipfile.lockfile has not changed since the last successful build, and (b) thePipfile.lockfile does not containgitreferences: https://github.com/heroku/heroku-buildpack-python/blob/d1ca05a398eed6824f29bf91176f5bd86e463f7a/bin/steps/pipenv#L9-L22However, there are other cases where
pipenv installstill needs to be run.For example, imagine a
Pipfilecontaining:Since
editable = falsethe local package will be copied intosite-packageson the initial build (rather than the original source linked via a.pthfile, as happens for editable installs). And then on subsequent builds if no other changes have been made toPipfile.lock, thepipenv installstep will be skipped, even though changes could have been made to files underpackages/mypackage/.(Note: The above is assuming a Pipenv version is being used that is not affected by the regression https://github.com/pypa/pipenv/issues/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.lockfile:gitcheck unless we resort to properly parsing the file (xref #1398)pipenv installis 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.