Nix+Haskell project template with IDE support - Haskell

What I've been using for my projects. It might be useful to others:

https://www.srid.ca/haskell-new-project.html

The note is only a rough outline; it could be improved with elaborate steps (PR welcome)

What do you think about mine? Just need to add hls too I think. I have it documented with useful things you might wish to do! It uses niv

https://github.com/bolt12/nix-hs-template

I'll have to look at it in detail. Mine is not really a template, but more of a documented "list of steps" you can do to get your project layout. Basically a bunch of commands. I might get to evolving it to a bunch of "recipes" (howtos). Like, "How to add docker image to your Haskell Nix project". So you have a bunch of independent recipes/howtos that can be composed to create/evolve a Haskell project to your liking.

Another reason why mine remains documented steps, rather than software template is that these are evolving preferences, with no "perfect" project layout suiting everyone at all stages in their career.

Pardon my ignorance, but can I use Nix as a Cabal/Stack replacement? I've seen Nix everything and still don't know what all the fuzz is about.

there are some experiments like https://github.com/nmattia/snack but I know of nothing that's production ready. you'll need at least cabal

Nix is more general than stack, and it replaces stack. Cabal is everywhere, and Nix uses it.

You don't need snack? Just use nix-shell in conjunction with cabal.

Nobody uses nix-build during development; and nix-shell in conjunction with ghcid, cabal new-repl or haskell-language-server is the typical workflow

Sridhar Ratnakumar said:

Cabal is everywhere, and Nix uses it.

This is sad. I don't like Cabal. There has never been another package manager for Haskell? What is the history behind Cabal?

I personally use nix with stack

@Sridhar Ratnakumar definitely, you can maybe take apart some of the things I use and create independent recipes for each one

That's a much better idea

I used to only use stack, but cabal is pretty good now. I still use hpack and it's mildly annoying that I have to manually run it to generate the cabal file, but other than that... it's just pretty much the same commands as with stack.

(but without the annoyances stack has with nix, and it's so easy to just use callCabal2nix rather than haskell.nix)

Vladimir Ciobanu said:

it's mildly annoying that I have to manually run it to generate the cabal file

I just run my hpack script whenever a .yaml file is written!

@Vladimir Ciobanu I .fine using stack + nix without haskell.nix. stack just uses my stack.nix file as you can see from my template

@Bolt problem is I end up using cabal anyway through callCabal2nix because that's how I deploy binaries to servers (via nix-copy-closure).

I'm not familiar with nix-copy-closure but that seems cool!

@Torsten Schmits , Sure but I have to remember doing it. Maybe some vim plugin to do it for me whenever I save a yaml file...

@Bolt , It's super cool. You can ssh-copy anything in your store to a different computer, and it will copy all the dependencies as well. No need to compile on that server! Which is quite relevant for running small NixOS servers that can't build lens/big Haskell libs, but can run the results!

Vladimir Ciobanu said:

Torsten Schmits , Sure but I have to remember doing it. Maybe some vim plugin to do it for me whenever I save a yaml file...

that's what I meant :sweat_smile: just autocmd BufWritePost *.yaml !ops/hpack.bash or whatever

@Vladimir Ciobanu that might be extra cool to cross compile to ARM and then ssh-copy to an rpi or something! Nice!

Indeed. All you need is ssh access!

Pedro Minicz said:

Sridhar Ratnakumar said:

Cabal is everywhere, and Nix uses it.

This is sad. I don't like Cabal. There has never been another package manager for Haskell? What is the history behind Cabal?

why you hate Cabal? is it because the old blog ranting about Cabal? Cabal is pretty good these days. And it's more advantage over stack nowadays. I've seen senior haskell devs, said that stack can cause you a trouble when your project grows very big

and, snack is not maintained, so avoid using it. Just use simple nix-shell.

Vladimir Ciobanu said:

Bolt , It's super cool. You can ssh-copy anything in your store to a different computer, and it will copy all the dependencies as well. No need to compile on that server! Which is quite relevant for running small NixOS servers that can't build lens/big Haskell libs, but can run the results!

That's how I deploy big ass ghcjs projects to measly $5 digitalocean droplets. nix-copy-closure is one way, another way (that I use currently) is to expose your home machine, via wireguard, to the internet and make it serve its /nix store as cache. https://twitter.com/sridca/status/1308808239677571072

Setting up your own Nix cache (Linux) is pretty easy with @nixos_org. https://nixos.wiki/wiki/Binary_Cache If using a home-machine, use @WireGuardVPN to expose it via a $5 @digitalocean droplet "facade". That is how I run some internet-exposed services on my P71 workstation at home.

- HAIETMOBA (@sridca)

it is also quite notable that using cachix makes the exposition of your machine's store unnecessary

and you get 10G compressed store for free

cachix is slow. separate external caches in general are

you have to push to, and download from, cachix. that's 2x asset transfer.

it is nice for small open source projects though

Rizary said:

why you hate Cabal? is it because the old blog ranting about Cabal?

I am not aware of this rant. I just had horrible experiences trying to install some stuff from hackage about a year ago. I remember a bunch of command line options having a "version 2", which is just ugly. Why not completely remove the old cruft?

Pedro Minicz said:

Rizary said:

why you hate Cabal? is it because the old blog ranting about Cabal?

I am not aware of this rant. I just had horrible experiences trying to install some stuff from hackage about a year ago. I remember a bunch of command line options having a "version 2", which is just ugly. Why not completely remove the old cruft?

version 2 command is already a default command. So you just need to run cabal build instead cabal new-build. They cannot completely remove it because some users still use the version 1 command at that time. But now, version 2 is already the default command without new- prefix.