[nickjj]

1. Build Docker image out of requirements.txt

2. Develop application

3. Repeat 1-2 until ready to deploy

4. Run Docker image in production with same dependencies as development

5. ??

6. Profit!

As long as you don't rebuild in between steps 3-4, you'll have the same set of dependencies down to the exact patch level.

[jbergknoff]

This has the added benefit of letting you encode the system dependencies (OS packages) for library build time and for run time.

Docker images are also a great way to distribute Python CLI tools, certainly far better than installing via pip which either pollutes global state or is confined to a certain project's virtualenv.

[koolba]

Bingo. If you’re not vendoring the binaries of your dependencies as part of a release then you’re doing it wrong.

It doesn’t have to be docker, containers just makes it easy to have immutable snapshots. Anything that packages it all up (including a simple tarball) is enough.

[minitech]

Doesn't help developers not get different versions of packages. Lockfiles are necessary regardless of Docker.

[RossM]

This is important (though I'm oddly yet to run into this issue with pip; I've only had conflicts with npm and composer before). Freezing dependency sources in Docker images and using (pip install --require-hashes -r requirements.txt) for development seems to cover everything.

[fernandotakai]

yeah, i was going to say the same: i never had that issue in ~7y of python work.

nowadays, requirements + docker solves 99% of everything i do.

maybe it's because i'm not using numpy and the likes?