Haskell developer experience in NixOS
kuznero.com
kuznero.com
RUN apt install -y build-essential
RUN apt install -y libopenssl-dev
RUN cd src && ./configure
Any sort of snapshotting at file system level (e.g. ZFS) would do the job as well, but Docker puts it together in a convenient way.
I guess Nix is better by using a DAG, but it's probably more complicated and harder the reason about (at least for those of us lacking in headspace).
This is a common misconception but there's plenty of info out there if you want to find out how to do it. https://duckduckgo.com/?q=reproducible+builds+in+docker&atb=...
In essence, you can make reproducible builds in docker by controlling the build environment and then specifying particlar versions when installing dependencies. It's a bit more work but it's eminently doable.
You control the build environment by building your reproducible docker containers within an environment (eg a reproducible docker container) that is itself reproducible (ie with specified versions of everything). This seems like a bootstrapping problem, but actually it works.
So: 1. Make a "Build container" with a specified base image version and specified versions of the transitive deps of everything it needs to build your thing 2. Use this container to build your actual container, specifiying a version of the base image and all dependencies.
Pretty sure you don't need more than these two layers of the onion to make bitwise-identical builds as long as your package build recipe is itself reproducible (eg the toolchain supports it and you don't do anything like embedding timestamps etc in the binaries).
Package managers provide mechanisms to get the version list in force so generally the way to do this is to start with your preferred base image, install all the packages you want/need, use the package manager to give you the version list, then change the Dockerfile to install specifically those versions.
Nix would be an excellent way to achieve this.
In theory. In practice, anything that doesn't hit the NixOS cache server will likely have been removed; it doesn't cache the build inputs, and links break all the time. On smaller timescales it's brilliant, though.
Absolutely not. It's made far easier to reason about through the fact that all of its features are exposed through a pure-functional language, giving the reader the ability to reason about each expression inside each level of brackets individually. It's extremely freeing reasoning about code once you realize you can rule out side effects.
TL;DR: I install a lot of packages to try them out and want an easy way to roll them back with as few consequences as possible. Nix seems to fill that gap.
As a student this really appeals to me; I usually think in broad terms initially, maybe write a proof or two to make sure I'm doing what I think (read: hope) I'm doing. Implementation is an afterthought for me, and so when it finally comes time to implement something I'll usually start at the typical "what are my options" phase.
For domains that I'm strong in I have a good idea what's available and it's probably already installed. But sometimes you're just /new/ to something and need to try things out. Sure, an API seems good in theory, but how does it work out in practice? Too much boilerplate? Does it work well with everything else I want? Did/does the original author share similar use cases to me? Is it (well) maintained (still)?
Of course, by the end of this process any number of things could be installed; both things I asked for, and things I didn't, are available to me. The issue that I then run into, and that Nix seems to solve for me, is that I want to undo portions to the installation and all their unintended side-effects. Beyond that, an easy way to manage groups of packages and roll them back en masse (again, including unintended side-effects) would be so beautiful.
In the case of Haskell, I have created chroots just to keep Haskell penned away from the rest of my system. I don't need pacman yelling at me because I `cabal install`d something and now the owner is wrong, my hair is on fire, and the universe is imploding. Nix seems like a much better way to handle this.
Of course, I could just be naive and/or uninformed-- likely both. I'd welcome sage wisdom from Haskell programmers on how to properly, cleanly manage package installs without getting in trouble with the system package manager (short of creating packages myself). And I've no doubt this has been solved outside of Nix using methods beyond rigorous self-control.
Marking it with the year is extremely relevant for me since I’ve been doing a lot of reading on NixOS and was hoping this was a new article.
As it is, it’s an interesting recap of someone discovering Nix.
https://github.com/shawndellysse/effuvv
NixOS is awesome, but it requires you to relearn all your sysadmin techniques; this is great in the long run but not so great in the short run. effuvv tries to be a solid middle-ground between traditional linux and functional system management