4 ms·
Reproducibility? No. Not having to regularly rebuild the whole dev environment because I need to work on one particular Python app once a quarter and its build
by Shog9 1y ago
Reproducibility? No.
Not having to regularly rebuild the whole dev environment because I need to work on one particular Python app once a quarter and its build chain reliably breaks other stuff? Priceless.
- janjongboom 1y agoThis false sense of reproducability is why I funded https://docs.stablebuild.com/ https://docs.stablebuild.com/ some years ago. It lets you pin stuff in dockerfiles that are normally unpinnable like OS package repos, docker hub tags and random files on the internet. So you can go back to a project a year from now and actually get the same container back again.
- jselysianeagle 1y agoIsn't this problem usually solved by building an actual image for your specific application, tagging that and pushing to some docker repo? At least that's how it's been at placec I've worked at that used docker. What am I missing?
- jamwil 1y agoPerhaps more focused on docker-based development workflows than final deployment.
- fcarraldo 1y agoBuilds typically aren’t retained forever.
- lmm 1y agoWhat do you do when you then actually need to make a change to your application (e.g. a 1-liner fix)? Edit the binary image?
- xylophile 1y agoYou can always edit the file in the container and re-upload it with a different tag. That's not best practice, but it's not exactly sorcery.
- lmm 1y agoIt's not, but at that point you're giving up on most of the things Docker was supposed to get you. What about when you need to upgrade a library dependency (but not all of them, just that one)?
- jselysianeagle 1y agoI'm not sure what the complication here is. If application code changes, or some dependency changes, you build a new docker image as needed, possibly with an updated Dockerfile as well if that's required. The Dockerfile is part of the application repo and versioned just like everything else in the repo. CICD helps build and push a new image during PRs, or tag creation, just like you would with any application package / artifact. Frequent building and pushing of docker images can over time start taking up space of course but you can take care of that by maybe cleaning out old images from time to time if you can determine they're no longer needed.
- zmmmmm 1y agoyou append it to the end of the docker file so that the previous image is still valid with its cached build steps
- lmm 1y agoAnd just keep accreting new layers indefinitely?
- jselysianeagle 1y agoDocker re-uses layers as needed and can detect when a new layer needs to be added. It's not like images grow in size without bound each time something is changed in the Dockerfile.
- northzen 1y agoUse pixi or uv to maintain this specific environment and separate it from the global one
- sroerick 1y agoI know this pain, and Docker absolutely makes sense for this use case, but I feel like we would both agree that this is a duct tape and bubble gum solution? Though a totally justifiable one
- Shog9 1y agoOh sure. 20 years ago I used VMs and that was also a duct tape solution. I'd have hoped for a proper solution by now, but a lighter hack works too