7 ms·
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 dependen
by nickjj 8y ago
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.
- koolba 8y agoBingo. 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.
- jbergknoff 8y agoThis 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.
- minitech 8y agoDoesn't help developers not get different versions of packages. Lockfiles are necessary regardless of Docker.
- RossM 8y agoThis 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 8y agoyeah, 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?