The official documentation also describes how to work with Cabal/Haskell:
The situation seems to have gotten a bit simpler with newer versions of the nix tools (this is of no fault of the author of this post, the post is more than a year old, their blog has great haskell stuff!).
Anyway, for haskell development you can just:
1. Write cabal file (e.g., ./project.cabal)
2. cabal2nix --shell . >shell.nix
4. cabal sandbox init
5. cabal build
Also their user manual is really good now.
I do not read this and go "This is a great idea and process!" I read this and say, "I can see how this might be better than the existing haskell toolchain. Cabal-dev has always been a bit of a compromise." (Edit: showing how long it's been since I have used Haskell in anger, cabal-dev got deprecated in favor of native sandboxing about 2 years ago, my bad.) Haskell seems to be the common thread for nearly all users of Nix I've encountered in the wild.
Honestly, do other people read this and go, "This seems better than my current development toolchain?" ESPECIALLY if you're producing static binaries? As much as I criticize Maven, I'm not sure what this process buys you over maven except... well... what DOES it buy you over Maven dependency management? Unification with OS packages?
It's not immutable, reproducible deploys. The deploy side is easy to render immutable and reproducible with layerd, controlled, tagged containers. It seems to be a story that's more about the build and dev side of things. Heck, I showed this to a co-worker and he said, "Wow, cabal must be really bad if someone was so frustrated by it that their solution was to change their OS."
I don't mean to throw shade on the work that the Nix and NixOS people have been doing. I understand it has value to some people. It just seems very oversold as a solution to the problem of reproducible dev environments. And by adopting Nix, you MUST deploy your executable to something that can play nice with Nix's expectations, even if you are making a static executable. This seems like a heavy price to pay.
A solution that works good enough is often a serious obstacle for developing a solution that works really well. E.g. Unix works just good enough to preclude the adoption of a new paradigm in OS'es such as Plan 9.
Treating packages like immutable values sounds like a genuinely new idea. So what I think is that people don't go "this seems better than my current development toolchain", instead they think that the idea that underlies Nix might result in disproportionately more reliable tools in package management. That's worth fussing about.
Disclaimer: I am not associated with Nix in any way.
I agree that using Nix doesn't make sense for application development where all the dependencies are resolvable within the language runtime. (Provided the runtime itself can be well-specified in the project configuration and the language's dependency management system defaults to exact immutable declarations.)
But throw in a dependency on Redis and Postgres, and you get into territory where traditional tools fall over pretty quickly, especially if different branches of your codebase depend upon different versions of Redis.
Personally Guix is more interesting to me as a way to keep my own stuff declarative rather than for sharing across a team of developers. But the cost doesn't seem too high if your application has external dependencies which traditional tools suck at; I've felt that pain and it isn't pretty.
Surely you would just depend on the driver, which is most likely going to be written in your high-level language.
A better point may be languages which rely a lot on C libraries (think Ruby and Python), and where having something like pip won't magically install the ImageMagick dependency your software needs.
Traditional dependency systems force you to track the version of the server itself outside the project's configuration.
And if you were to make such a decision, then you'd capture it in the closure required to run the code you built, so you'd sort of bake in the inclusion of those services into any deploy of your code, using Nix's philosophy.
Or am I misunderstanding you?
I'd argue Nix is nicer for everything but Haskell because the way Nix thinks about versions doesn't fit projects as neatly as one would think. As a Linux distro it's nifty (fully systemd-ified).
Cabal sandboxes have "just worked" since release in my experience (my own, plus hundreds of IRC users I've helped).
But I sort of struggle to imagine using NixOS to ship products, as it would mandate every dev maintain a comparable NixOS environment for development. In a world where even editor choice can be contentious and user-facing Linux only runs well on a small handful of machine types, this seems a little unfair.
A development team has to standardize on some things. Everyone might use their own text editor, but everyone can't use their own dependency management system.
> but everyone can't use their own dependency management system.
This is untrue. Different disciplines use different tools for dependency management and it's not clear to me that the world is crying out for a unification here. Golang developers use one, Nim developers use another. Java developers have different requirements still.
Let's look at a pair of closely related langauges, Clojure and ClojureScript. While we might want a uniform method for DECLARING dependencies, the specific mechanisms used to fetch those dependencies may (and possibly should?) be different.
And, as I've noted in the past, these packages people make as afterthoughts to product development are often broken. You end up welding your dev environment directly to your deployment environment and you complicate cross-platform builds quite a bit (closures cross-platform are, unless they have changed since early this year, not really a well-formed proposition).
I also wrote a bit of nix code to read the package.json file and figure out what the direct dependencies are, which keeps derivations for my own packages simple.
I've recently nixified the (really very complicated) deployment of our main webapp at work and I now have the entire setup of the webapp defined in about 5 .nix files. That's a really relaxing place to be in (compared to how things were before).
Nix provides repeatable deployments at the package level. The destination environment can be a user's environment, a container, a VM, a cloud instance, an NixOS machine, an HTTP server or whatever.
Once you're using nix, I don't see any point in using Docker. If you're running Mesos or something like that, it might be worthwhile to build containers for deployment, but if all you want is your packages on a server, Nix gives you that out of the box.
I've brought it up a few times with Joyent folk, but they haven't looked at it seriously. I think they're so spooked by Docker that they can't pay attention to anything else.
My team builds a distributed application. We have nix expressions that define packages for all the parts of the application, and systemd services to run them on NixOS. Using those packages:
• Our production deployment is defined by some Nix expressions that assign the services to different machines in the cluster.
• Our staging deployment is a Nix expression that runs all the services on a single machine.
• Our development deployment is a Nix expression that creates an environment where all dependencies are available and the application can be executed by hand.
What is cool though is that containers are supported natively in nixos (through systemd) https://nixos.org/releases/nixos/14.12/nixos-14.12.374.61adf...
Also, quite similar to 'cloud-config' I guess, there's a way to declaritively describe deployments to your favorite Cloud Provider TM https://nixos.org/nixops/
As the world is moving to declarative deployments, and once the docker hype settles, I think operating systems like NixOS will prevail as they're a great solution to the problem.
I was going to say Debianesque, but I kept deleting whatever I wrote in its place because I just thought it would lead to off-topic trolling.
In short: I wanna build my own Arch Linux, and Arch User Repository, but using Guix. We shall see if I ever do that as I promised myself in the next 5-10 years. Haha.