

How I develop with Nix - ayberkt
https://ocharles.org.uk/blog/posts/2014-02-04-how-i-develop-with-nixos.html

======
ocharles
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...](https://nixos.org/nixpkgs/manual/#users-guide-to-the-haskell-
infrastructure)

------
buttproblem
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
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/down...](https://hydra.nixos.org/job/nixpkgs/trunk/manual/latest/download-
by-type/doc/manual#users-guide-to-the-haskell-infrastructure)

------
KirinDave
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.

~~~
ayberkt
The thing about Nix is that it's the first project, as far as I know, that
tries to solve the problem of package management with a fundamentally
different approach. Most of the solutions to date were just okay: they worked
with a tolerable degree of failure.

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.

~~~
yenda
The first but not the last, there is also Guix the package manager and GuixSD
the system distribution, which is written in Scheme, as well as all the
package definitions. For lispers it is heaven.

~~~
KirinDave
I am assuredly a "lisper" and I really don't want to use anything based on
Nix. I really dislike how statically linked executables are not portable on
Nix. I'm less upset w.r.t. dynamic library management.

------
cwp
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
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
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.

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

~~~
ocharles
Indeed, it works as nicely as you'd expect! I have a blog post in the pipeline
describing how we do deployments... I need to get that pushed out.

~~~
boothead
... Indeed you do :-)

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

~~~
ris
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...)

~~~
pbowyer
Please file bug reports for your issues - it'd be much appreciated by the rest
of us.

~~~
ris
I'm often using quite unconventional setups and am often unsure whether it's
just something I've done.

------
616c
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
GUIX has non-gnu stuff available too.

~~~
616c
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
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_anothe...](https://nixos.org/wiki/How_to_install_nix_in_home_\(on_another_distribution\))

~~~
themckman
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.

