utdemir/hs-nix-template

A Haskell project template that uses Nix and comes with cabal-install, ghcid, ormolu, haskell-language-server and more.

hs-nix-template's Issues

Adding hpack?

Hey, I recently discovered this template and it is super helpful. I was wondering if you think adding hpack would be beneficial to the template? The nix build automatically picks it up and you don't have to add all of your modules to the cabal file.

I would gladly do the work, but I wanted to see if it aligns with your view of the project :)

Change testing framework to tasty-discover

I'm thinking of changing the test framework to tasty-discover. The reason is that, it also supports more conventional unit tests rather than property tests.

What do you think @Skyfold ?

Edit: Looks like tasty-discover is not maintained. Maybe we can just go to plain tasty. Do you know any alternatives which supports both property tests and unit tests?

Adding some workflow examples

My plan is to add:

• How to add new development tool or dependency with niv (and link back to niv repo)
• Note about keeping a nix-shell open while changing default.nix or using lorri
• link how to setup docker builds

Let me know if I'm putting too much information.

github actions workflow with multiple lines?

hs-nix-template/.github/workflows/build.yaml

Line 19 in 9247811

- run: nix-build ci.nix --argstr use_hpack "${{ matrix.use_hpack }}" --argstr add_executable_section "${{ matrix.add_executable_section }}"

While working on #22, we tried using the multiline syntax (from https://yaml-multiline.info). Basically, writing,

 - run: >-
   nix-build ci.nix
     --argstr use_hpack "${{ matrix.use_hpack }}"
     --argstr add_executable_section "${{ matrix.add_executable_section }}" 

However, this caused CI to fail. I tried both >, >- and,

 - run: |
   nix-build ci.nix \
     --argstr use_hpack "${{ matrix.use_hpack }}" \
     --argstr add_executable_section "${{ matrix.add_executable_section }}" 

None of these work. If anyone knows how these things work that would be great :)

Optionally add `relude` and common GHC extensions

relude is my go-to custom prelude, and I currently spend time adding the required mixins' section. Same with some GHC extensions.

I'd enable them unconditionally if this project were only for me, but it'd probably make other users happier if we prompt at the beginning.

"Prefer composable approach"

There is an issue in haskell-nix repo suggesting a few good practices, and they all make sense to me. I think we should apply them to our template too.

To quote:

The examples use methods that cause issues when trying to extend the package set further. Using the right tools, which are no harder, we can avoid frustration down the line.

• Use overlays instead of overrides. They are the way to go, because they are more powerful and, I'd argue, more consistent: overlays for packages sets, overrides for packages.
• Avoid rec keyword. People get used to it and will use it in overlay definitions, leading to surprises.
• Use haskellPackages.extend instead of .override { overrides =. It lets you add more layers of overrides which is more flexible. Attempting the same on the current code replaces the single layer of overrides with the new one, which is unexpected. As a bonus, it is syntactically simpler.

I think the first and third point is relevant to us.

Hedgehog seems to builds from source

I'm stuck on windows for a bit so I'm trying out hs-nix-template from a new VM. It seems that hedgehog has to be built from source for some reason and that takes forever and it seems its dependencies also have to be built from source.

[demo@nixos:~/code/test-nix-template]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 5.4.35, NixOS, 20.03.1577.74a80c5a9ab (Markhor)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.4`
 - channels(root): `"nixos-20.03.1577.74a80c5a9ab"`
 - channels(demo): `"home-manager"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Add the 'executable' section conditionally

Currently hs-nix-template generates a package with a library, executable and a test-suite.

In my experience, users usually create a library than an executable. So, hs-nix-template should prompt the user if an executable section is necessary, and only conditionally create the section and the related app/ directory.

Add license

I'd like to fork this if only to have a public CI to see errors but there isn't a license, can you please add one?

Summoner integration and more

Hi, I stumbled upon this repo from reading https://discourse.nixos.org/t/nix-haskell-development-2020/6170 and it was very useful in my journey with nix.

I developed a personal version that includes summoner Haskell project scaffolding and lorri integration! Unfortunately it's not a fork but I'm opening this issue to share what I did since it can fit other persons necessities too.

The repo is here: https://github.com/bolt12/hs-nix-template

Please tell me if you think I stepped a line somewhere.

Leverage Recursive Nix to have more comprehensive tests

Nix 2.4 is supposed to be released soon (famous last words), which should support invoking Nix inside Nix derivations.

That would allow us writing more tests like

1. Generate the project
2. Enter to a nix-shell (this part we can not do yet)
3. Run cabal build.

Flake support

The upcoming flakes feature of Nix simplifies the setup on that project, so I think we need to migrate to it once it is released.

Actually, using https://github.com/edolstra/flake-compat we could even use the flake-based setup today, however it lacks many niceties coming with flakes, so I still think we should wait for an official release.

An example Haskell project using flakes is here: https://github.com/utdemir/nix-tree

Add another branch with Haskell IDE Engine

I've been getting hie working locally to see how it works in practice. There are a few downsides to getting it setup: You need to either compile it yourself (2 hours plus) or set your nixpkgs to the same checkout as one of the pre-built ones that you can get on cachix (see this repo). I've been running into issues if I use a different checkout of nixpkgs even if I use the correct version of ghc and cabal. There is also a hack I need to write to get hie to find the hoogle database. Either way I would want to put the setup with hie in another branch so users can choose to just use ghcid (which always works).

Note: Setting up cachix is more difficult than I thought since we cannot just upload the shell derivation since it will be different for each user. Instead we would need to build the parts individually.

Validate user input to avoid creating malformed files

Currently most of the inputs we allow are raw strings. The user can easily pass incorrect values (project names with disallowed characters, module names that does not fit haskell syntax).

We should have a script which validates them to ensure that the files we generate are correct.

It doesn't have to be a super strict validation, I am happy if a dedicated user can break it; but we should at least protect for simple mistakes.