heroku-buildpack-python: Deploy fails due to outdated Pipfile.lock

Just to report some success in solving it and another work around:

@mcescalante and I ran into the same issue today. In our case it was fixed by removing a requirements that was to be installed from GitHub (c.f. https://github.com/OpenHumans/oh-fitbit-integration/pull/16/files#diff-1e61a31bf9b94805f869dc4137ec1885L20).

After removing the corresponding requirement the build on heroku would go through without any problems. As an alternative to that heroku buildpacks:set https://github.com/heroku/heroku-buildpack-python\#v134 did the trick as well.

setting SKIP_PIPENV_INSTALL didn’t work

Environment variables set in the app’s config are not set in the environment during the build by default - instead individual steps during the build have to load them in from ENV_DIR (using the sub_env helper). See: https://devcenter.heroku.com/articles/buildpack-api#bin-compile

I presume this is intended to prevent the build being broken by an app having variables set that shouldn’t be, but it does mean that it’s currently not possible to set SKIP_PIPENV_INSTALL manually (perhaps the maintainers of this buildpack would be open to changing this?).

For now an alternative workaround (instead of pinning to an old buildpack version), would be to use the pre_compile hook to delete Pipfile and Pipfile.lock before they are detected and used: https://github.com/heroku/heroku-buildpack-python/blob/master/bin/steps/hooks/pre_compile

To do that, create a script named bin/pre_compile in your app’s repository, containing:

#!/usr/bin/env bash

# Make non-zero exit codes & other errors fatal:
# http://redsymbol.net/articles/unofficial-bash-strict-mode/
set -euo pipefail

# Prevent heroku-buildpack-python from using pipenv instead of pip and requirements.txt.
rm Pipfile Pipfile.lock

@adamkowalczyk It should be https://github.com/pypa/pipenv/issues/2219 and fixed in https://github.com/pypa/pipenv/pull/2301

Just implemented it and it works like a charm!

This will allow us to keep dependencies under pipenv management / enjoy its support for working with virtualenvs, and, at the same time, hopefully never again waste days on fixing pipenv related problems on Heroku / always have a stable requirements.txt fallback.

@edmorley as to your additional point, thanks for this valuable hint as well, I’ll just add a check to our CI script to compare requirements.txt and pipenv lock -r output to avoid forgetting to update requirements.txt, and hitting resulting problems w.r.t. systems parity.

I wish Heroku engineers were as helpful and responsive as you guys, so glad I stumbled upon this issue 👍