Docker image build not deterministic/reproducible, uses setup.py not Pipenv.lock, differs from dev env

[javabrett]

TL;DR: current Docker image built today will include greenlet version 0.14.4, whereas dev environments get 0.14.3 from Pipenv.lock.

This issue:

• Is based on the thinking that the Docker image represents an Application build/deployment of httpbin, as opposed to httpbin as a Library, ref https://docs.pipenv.org/advanced/#pipfile-vs-setuppy
• Assumes that the Docker build should be good for both production and development uses (but might be better-suited to one or the other)
• Assumes where possible, and within some of the challenges presented by Docker to make reproducible builds (such as moving tags for base images), that the httpbin Docker image build should make best-efforts to be deterministic and reproducible

To illustrate this issue I am making-use of the fact that for current master @ fce4d83 Pipfile.lock, greenlet is at version 0.14.3 and a new version 0.14.4 has been released since the last pipenv lock was committed.

Part of my motivation for this issue is that I have been learning pipenv and want to develop some best-practices. The install of httpbin into a Docker image seems interesting, since it runs under gunicorn effectively as a Library, but the deployment context is more of an Application, and we might expect reproducible builds and installations.

Expectation: When developing using pipenv, the versions we get from Pipenv.lock we expect to be the same versions in a Dockerfile built from the same Git revision today, and the same Git revision in the future.

Observation: When the current master revision was committed Thu Jul 12 2018, greenlet version 0.14.3 was the newest released and is the version in Pipfile.lock and would also appear in the Docker image. When building today, pipenv sync and pipenv shell produce version 0.14.3, but the Docker image via setup.py and setuptools gets the latest version of greenlet, 0.14.4.

Assuming this should be fixed, I have a couple of approaches which work by either generating a requirements.txt or running a pipenv within the container. But wanted to get feedback first.