9 ms·

How I develop with Nix

144 points by ayberkt 11y ago

davexunit 11y ago
nix-shell is a killer tool. A generic virtualenv that doesn't duplicate dependencies if you use it for multiple projects.
- ris 11y ago
  For me it has a few too many annoying shell quirks for me to use daily (try a ctrl-c inside a psql prompt - always screws up my screen session for some reason...)
  - ocharles 11y ago
    Are you using --pure? I'd imagine these problems are from lost environment variables, but only --pure should clobber those.
  - pbowyer 11y ago
    Please file bug reports for your issues - it'd be much appreciated by the rest of us.
    - ris 11y ago
      I'm often using quite unconventional setups and am often unsure whether it's just something I've done.
buttproblem 11y ago
I was just trying to get Nix working after needing a version of base (GHC) newer than what I had installed. 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 3. nix-shell After step 3, all the required packages, including stuff like GHC, will be installed. You can use cabal however you normally do to build the project: 4. cabal sandbox init 5. cabal build
- psibi 11y ago
  Is step 4 really required ? nix-shell already gives you a sandbox environment. Also their user manual[0] is really good now. [0]https://hydra.nixos.org/job/nixpkgs/trunk/manual/latest/download-by-type/doc/manual#users-guide-to-the-haskell-infrastructure https://hydra.nixos.org/job/nixpkgs/trunk/manual/latest/down...
cwp 11y ago
Yup. This is pretty much what I do as well, but for Node and Python projects. The best part is that I develop in exactly the same environment that the app has in deployment.
- thinkpad20 11y ago
  I use nix with python at work, but I haven't yet used it (much) with our node libraries. `npm2nix` was a little clunky in my experience, generating an enormous expression for each package with no code reuse. Is it easier in practice?
  - cwp 11y ago
    Yeah, I use npm2nix a lot, and it does produce very large files (a few thousand lines of code). But in practice it's fine. I very rarely look at the generated code. If I need to update a dependency, I change my package.json file, run npm2nix and start a new nix-shell. 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.
- deleted 11y ago
  [deleted]
hlfw0rd 11y ago
Seems like it would be perfect for declarative deployments!! So neat!
- arianvanp 11y ago
  That's kind of the whole point of nix-os. Take the nix package manager and describe your entire OS decoratively. With atomic upgrades and rollbacks!
  - selestify 11y ago
    How does this compare to Docker?
    - jerf 11y ago
      NixOS is the whole OS. It doesn't use the kernel sandboxing at all, for itself at least, any more than any other distro does. Conceivably it could be used to replace CoreOS, though I'm sure that while at a high level that makes perfect sense there's an arbitrary number of incidental details that make that impractical, as is the way of these things.
      - arianvanp 11y ago
        It actually has kernel sandboxing built in. You can run nix expressions in linux containers. https://nixos.org/releases/nixos/14.12/nixos-14.12.374.61adf9e/manual/ch-containers.html https://nixos.org/releases/nixos/14.12/nixos-14.12.374.61adf...
    - davexunit 11y ago
      Much better and not restricted to only containers.
    - cwp 11y ago
      The appeal of Docker is that containers give you repeatable deployments. Once you have an image, you can deploy it in a well-defined way. But it punts on the question of how you build the image. 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.
KirinDave 11y ago
Recently I've been in various threads on HN complaining about how frustrating the Nix story is for development. 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.
- coolsunglasses 11y ago
  Nobody's used cabal-dev in Haskell-land for ages. Cabal has had native sandboxing since mid-2013 and Stack is a more recent alternative. 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).
  - KirinDave 11y ago
    Sure, the last time I deployed Haskell for a paycheck it was still cabal-dev. I'm absolutely out of date there. 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.
ocharles 11y ago
It's worth noting the landscape has changed since I wrote this blog post. My updated workflow is here: http://wiki.ocharles.org.uk/Nix http://wiki.ocharles.org.uk/Nix The official documentation also describes how to work with Cabal/Haskell: https://nixos.org/nixpkgs/manual/#users-guide-to-the-haskell-infrastructure https://nixos.org/nixpkgs/manual/#users-guide-to-the-haskell...
616c 11y ago
I see people mentioning it on other threads, but is anyone usigin Guix? Or the dmd daemon system? I am curious because the GNU package set is quite limtied for obvious reasons, but I still would love to work my way up to a homegrown OS or fork where I add the non-GNU-compliant apps and build my own master OS for the elitist Lispter (see what I did there) I aspire to be.
- anthk 11y ago
  GUIX has non-gnu stuff available too.
  - 616c 11y ago
    Oh I am aware, I just did not want to get in to the OSI and GNU spectrum of licensing. 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.
CrystalCuckoo 11y ago
I love Nix, but I wish there were a way to easily install packages without having sudo access. Programs like pip only need a '--user' flag, while Nix requires you to use chroot magic[1] to be able to install packages in your home directory. [1] https://nixos.org/wiki/How_to_install_nix_in_home_(on_another_distribution) https://nixos.org/wiki/How_to_install_nix_in_home_(on_anothe...
- themckman 11y ago
  I sort of "version" or segregate my $HOME directory into a separate Workspaces directory in my real home for which I then have a script to activate a particular work space. For the most part, this script just sets $HOME and execs a new /bin/bash. This works pretty well. Most everything respects the new $HOME and works from there (so far only SSH and Java seem to ignore this to which I think I could fix Java by setting $JAVA_OPTS and explicitly setting the user.home property). On OS X I can install a separate copy of homebrew for each work space and have only the packages in each work space that I need or want. I was really looking forward to doing the same thing with Nix when I recently switched to Linux at my new job, but was very disappointed to find out that it really wanted to be installed somewhere in the root file system. Thanks for the link, I hadn't come across that one yet. I might give that a try.

144 points by ayberkt 11y ago

nix-shell is a killer tool. A generic virtualenv that doesn't duplicate dependencies if you use it for multiple projects.

ris 11y ago
For me it has a few too many annoying shell quirks for me to use daily (try a ctrl-c inside a psql prompt - always screws up my screen session for some reason...)
- ocharles 11y ago
  Are you using --pure? I'd imagine these problems are from lost environment variables, but only --pure should clobber those.
- pbowyer 11y ago
  Please file bug reports for your issues - it'd be much appreciated by the rest of us.
  - ris 11y ago
    I'm often using quite unconventional setups and am often unsure whether it's just something I've done.

buttproblem 11y ago

I was just trying to get Nix working after needing a version of base (GHC) newer than what I had installed. 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 3. nix-shell After step 3, all the required packages, including stuff like GHC, will be installed. You can use cabal however you normally do to build the project: 4. cabal sandbox init 5. cabal build

psibi 11y ago
Is step 4 really required ? nix-shell already gives you a sandbox environment. Also their user manual[0] is really good now. [0]https://hydra.nixos.org/job/nixpkgs/trunk/manual/latest/download-by-type/doc/manual#users-guide-to-the-haskell-infrastructure https://hydra.nixos.org/job/nixpkgs/trunk/manual/latest/down...

cwp 11y ago

Yup. This is pretty much what I do as well, but for Node and Python projects. The best part is that I develop in exactly the same environment that the app has in deployment.

thinkpad20 11y ago
I use nix with python at work, but I haven't yet used it (much) with our node libraries. `npm2nix` was a little clunky in my experience, generating an enormous expression for each package with no code reuse. Is it easier in practice?
- cwp 11y ago
  Yeah, I use npm2nix a lot, and it does produce very large files (a few thousand lines of code). But in practice it's fine. I very rarely look at the generated code. If I need to update a dependency, I change my package.json file, run npm2nix and start a new nix-shell. 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.
deleted 11y ago
[deleted]

hlfw0rd 11y ago

Seems like it would be perfect for declarative deployments!! So neat!

arianvanp 11y ago
That's kind of the whole point of nix-os. Take the nix package manager and describe your entire OS decoratively. With atomic upgrades and rollbacks!
- selestify 11y ago
  How does this compare to Docker?
  - jerf 11y ago
    NixOS is the whole OS. It doesn't use the kernel sandboxing at all, for itself at least, any more than any other distro does. Conceivably it could be used to replace CoreOS, though I'm sure that while at a high level that makes perfect sense there's an arbitrary number of incidental details that make that impractical, as is the way of these things.
    - arianvanp 11y ago
      It actually has kernel sandboxing built in. You can run nix expressions in linux containers. https://nixos.org/releases/nixos/14.12/nixos-14.12.374.61adf9e/manual/ch-containers.html https://nixos.org/releases/nixos/14.12/nixos-14.12.374.61adf...
  - davexunit 11y ago
    Much better and not restricted to only containers.
  - cwp 11y ago
    The appeal of Docker is that containers give you repeatable deployments. Once you have an image, you can deploy it in a well-defined way. But it punts on the question of how you build the image. 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.

KirinDave 11y ago

Recently I've been in various threads on HN complaining about how frustrating the Nix story is for development. 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.

coolsunglasses 11y ago
Nobody's used cabal-dev in Haskell-land for ages. Cabal has had native sandboxing since mid-2013 and Stack is a more recent alternative. 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).
- KirinDave 11y ago
  Sure, the last time I deployed Haskell for a paycheck it was still cabal-dev. I'm absolutely out of date there. 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.

ocharles 11y ago

It's worth noting the landscape has changed since I wrote this blog post. My updated workflow is here: http://wiki.ocharles.org.uk/Nix http://wiki.ocharles.org.uk/Nix The official documentation also describes how to work with Cabal/Haskell: https://nixos.org/nixpkgs/manual/#users-guide-to-the-haskell-infrastructure https://nixos.org/nixpkgs/manual/#users-guide-to-the-haskell...

616c 11y ago

I see people mentioning it on other threads, but is anyone usigin Guix? Or the dmd daemon system? I am curious because the GNU package set is quite limtied for obvious reasons, but I still would love to work my way up to a homegrown OS or fork where I add the non-GNU-compliant apps and build my own master OS for the elitist Lispter (see what I did there) I aspire to be.

anthk 11y ago
GUIX has non-gnu stuff available too.
- 616c 11y ago
  Oh I am aware, I just did not want to get in to the OSI and GNU spectrum of licensing. 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.

CrystalCuckoo 11y ago

I love Nix, but I wish there were a way to easily install packages without having sudo access. Programs like pip only need a '--user' flag, while Nix requires you to use chroot magic[1] to be able to install packages in your home directory. [1] https://nixos.org/wiki/How_to_install_nix_in_home_(on_another_distribution) https://nixos.org/wiki/How_to_install_nix_in_home_(on_anothe...

themckman 11y ago
I sort of "version" or segregate my $HOME directory into a separate Workspaces directory in my real home for which I then have a script to activate a particular work space. For the most part, this script just sets $HOME and execs a new /bin/bash. This works pretty well. Most everything respects the new $HOME and works from there (so far only SSH and Java seem to ignore this to which I think I could fix Java by setting $JAVA_OPTS and explicitly setting the user.home property). On OS X I can install a separate copy of homebrew for each work space and have only the packages in each work space that I need or want. I was really looking forward to doing the same thing with Nix when I recently switched to Linux at my new job, but was very disappointed to find out that it really wanted to be installed somewhere in the root file system. Thanks for the link, I hadn't come across that one yet. I might give that a try.