Hacker News Reader

Comment by _query | Hacker News Reader

If you're using docker on mac, you're probably not using it there for easy scaling (which was the reason docker was created back then), but for the "it just works" feeling when using your development environment. But docker introduces far too much incidental complexity compared to simply using a good package manager. A good package manager can deliver the same "it just works" feeling of docker while being far more lightweight.

I've wrote a blog post about this topic a few months ago, check it out if you're interested in a simpler way of building development environments: https://www.mpscholten.de/docker/2016/01/27/you-are-most-lik...

View on HN

The point of using Docker on Mac is to ensure that your local dev environment is the same as your deploy environment, and avoid that ever-delightful "well it works on my machine, not sure what's breaking on the build server" experience.

With respect, I'm not sure you really grok the value prop of docker as it relates to operations and delivery. (The "easy scaling" part is incidental to that, and not the primary purpose of Docker). Nix, while cool, does not address those issues.

Nix is more difficult. With Docker, you don't need to learn much new stuff, since images are created from sequences of ordinary shell commands running on familiar distributions. Nix requires you to familiarize yourself with a new package manager and its somewhat arcane definition language. And then also the specific Nix tools for working with npm, ghc, or whatever you want to use. So the experience is very different.

In this case you could still pick homebrew as your package manager of choice. It works pretty well, is available cross platform (https://github.com/Linuxbrew/linuxbrew) and is far more simple than docker. You just have write a short shell script which installs all the dependencies via brew when not installed already (much like you'd do in a Dockerfile).

Is Docker that difficult? The Dockerfile is a nice single file that defines all container dependencies and then it's three commands (build, create, and start) to be able to easily work in the exact same environment for dev, qa, and production regardless of whether the host is running OSX or a flavour of linux.

Brew doesn't offer you isolation - you cannot run multiple isolated applications with different dependencies at the same time.

But you can install brew in a subdir. For some projects i do exactly that. Project/.brew. I have a project/bin/activate which puts ./.brew/bin in your path. And there you go: postgres9.5 for this project and postgres 9.2 for that project. Still no isolation though. And having pg installed in a docker image is not a good example... But you getthe point :)

How does this solve the dev-prod parity issue (using the same versions of dependencies, etc.)?

No, package managers don't really have anything to do with this.

Nix can provision containers, VMs, bare metal. It is much more capable than Docker because it composes, and doesn't use opaque disk images as the basis for everything. Nix provides much better reproducibility.

Ditto with Guix. Reproducible builds FTW.

I'd like to have an equivalent of `guix environment` in Brew.

Tell that to guix container.

Reply on news.ycombinator.com