Exactly. I wanted to also point this out in the relation of the author's desire to put all build commands in `just` configuration file. It sounds to me like a desire to use some another "slick and shiny tool" (which `just` is when compared to `make`), but what's the point exactly? The build-process will still be container-dependent and may or may not work outside of the container, and you don't get the benefit of Docker caching anymore.

▲

simonw 5 days ago | parent [-]

Being able to run "just build" in a container-free local development environment and have the same build process run as the one in your production setup is a productivity boost worth having.

Same as how it's good to be able to easily run the exact same test suite in both dev and CI.

▲

krick 4 days ago | parent [-]

But wouldn't you run whatever you are writing in Docker container on dev anyway? I always did just that, as long as I use Docker as a deployment tool for a project at all. And, in fact, even sometimes when I didn't, since it's much easier and cleaner to keep, say, multiple php or redis versions in containers, than on your PC. And it's only maybe a year since it became actually effortless to maintain all this version-zoo locally for Python, thanks to uv. In fact, even when it's something like Go, so the deployable is a compiled binary, I'd usually wrap the build process into a Docker container for dev anyway.

	▲	simonw 4 days ago \| parent [-]
		Depends on how complex your stuff is. Most of my own projects run outside of Docker on my machine and run inside Docker when deployed. I have over 200 projects on my laptop and I don't want the overhead of 200 separate containers for them.