[RFC] Nix

[chshersh]

This issue tracks Nix support in Summoner. Nix seems to be widespread in the Haskell community, and some people can benefit from having Nix with established best-practices in scaffolded projects. This issue tracks both: building Summoner with Nix and generating projects with the Nix configuration.

Main goals

Below are the goals we want to achieve with implementing Nix support.

• Provide established, non-opinionated best-practices on Nix configuration for Haskell projects
• Has as little extra configuration as possible (ideally only a single file if Nix enabled; we already have support in Summoner to include any extra files)
• Make sure the Nix configuration is maintainable:
  • What needs to be done for Summoner in case of a library upgrade or GHC version upgrade?
  • What beginners should do if the default Nix config is not enough? I think that the generated Nix config should contain commented out pieces of code for different scenarios (depend on a library from Git, fix broken dependency, etc.)

Brief implementation plan

I've created the nix branch. All parts of the implementation should be submitted as PRs to that branch. It should be rebased on master when master updates.

Below I describe what parts of the Summoner need to be implemented or changed to support Nix:

• Add the Nix constructor to the Tool data type
• Ask the Nix question in CLI mode
• Add the Nix button in TUI
• Patch CI configurations to have Nix in there
  • Travis CI
  • GitHub Actions
• Add Nix script for the summon script command (issue summon script nix #349)
• Add nix field in the default configuration produced by summon config
• Add tests (both examples and on CI)
  • Add new nix-minimal example
  • Update full-batteries example
• Build Summoner with Nix (on CI as well)
• Update documentation

Open questions

1. How does CI for Nix look like on supported by Summoner integrations?
2. Should we add Cachix?
3. How to support multiple GHCs?
4. How are we going to maintain Nix support in Summoner and make sure it doesn't break over time?

History references

Previous attempts to implement some parts of this plan

• WIP: Add simple Nix support #166: Simple Nix support with cabal2Nix
• add nix and nixpkg scaffolding #283: add nix and nixpkg scaffolding
• Add support for building summoner using Nix #335: Add support for building summoner using Nix
• WIP: Add nix to travis matrix #344: WIP: Add nix to travis matrix

[qoelet]

Would this go along the lines of calling cabal2nix on the summoned cabal file?

[chshersh]

@qoelet I have only basic Nix knowledge, so I'm not sure what is required here. If this requires to call some tool each time .cabal file is changed, then, maybe it's a good idea to do this on CI and have one extra build that checks that CI with nix is passing. But, on the other side, this might complicate our .travis.yml significantly (it already contains a lot of logic to support both cabal-install and stack) and if we put Nix into it then I'm not sure we will be able to maintain this. And things become more complicated with tools like stack2nix and others.

So, adding nix support to generated Haskell projects and .travis.yml is good deal, but we need some DevOps experts here to recommend the best workflow 😄

[mgttlinger]

You can have nix automatically call cabal2nix like this:

{ haskellPackages, lib }:

haskellPackages.callCabal2nix "projectname" (lib.cleanSource ./.) {}

This way the nix build basically regenerates itself from the changed cabal file on the fly.

[mgttlinger]

If you point me to the right places to implement this I can send a PR.

[chshersh]

@mgttlinger Attempt to add nix support to summoner was given in this PR:

• WIP: Add simple Nix support #166

You can check the implementation and the discussion. I will be very happy if adding and maintaining nix to Haskell projects can be a very easy and simple task.

[srid]

For most non-complex projects, the following default.nix will do the trick:

# default.nix
let 
  pkgs = import <nixpkgs> { };
in 
  pkgs.haskellPackages.developPackage {
    root = ./.;
    modifier = drv:
      pkgs.haskell.lib.addBuildTools drv (with pkgs.haskellPackages;
        [ cabal-install
          ghcid
        ]);
  }

Then you can just run nix-shell and run cabal or ghcid or whatever, as usual.

Ref

[o1lo01ol1o]

For most non-complex projects, the following default.nix will do the trick:

It will do the trick, however, it might be nice to expose the basic overlaying functions necessary to override packages and and add derivations (since that part can be non-trival for people new to nix). Here's an example from hasktorch that overlays all the needed derivations to use hasktorch as a library (along with hie). The top-level default.nix file is generic and follows the above reference.

[srid]

developPackage is designed to be a simpler interface, and it supports package overrides as well (without having to explicitly manage overlays). It takes two arguments: source-overrides which may be used if all that is being overriden is the source location of a package, as well as the more general overrides which allows you to override the Haskell package derivations.

let
  pkgs = import <nixpkgs> { };
  compilerVersion = "ghc865"; 
  compiler = pkgs.haskell.packages."${compilerVersion}";
  hies = (import (builtins.fetchTarball
      "https://github.com/infinisil/all-hies/tarball/master") { }
  ).selection {
    selector = p: { "${compilerVersion}" = p."${compilerVersion}"; };
  };
in
  compiler.developPackage {
    root = ./.;
    source-overrides = {
      named = builtins.fetchTarball 
        "https://github.com/monadfix/named/archive/e684a00.tar.gz";
    };
    overrides = self: super: with pkgs.haskell.lib; {
      dependent-sum = doJailbreak super.dependent-sum;
      lens = appendConfigureFlag super.lens ....;
    }
    modifier = drv:
      pkgs.haskell.lib.addBuildTools drv (with pkgs.haskellPackages;
        [ cabal-install
          ghcid
          hies
        ]);
  }

[chshersh]

I've updated issue description with a more detailed implementation plan and goals we want to achieve if Nix is going to be supported by Summoner.

[bolt12]

I'm not very experienced in Nix but I've been looking around tutorials and opinionated guides and found these two: https://discourse.nixos.org/t/nix-haskell-development-2020/6170, https://medium.com/purely-functional/nix-setup-for-haskell-with-ghcide-and-hlint-3e268343efed to work out best. They seem to offer a solution that has the right abstraction granularity and flexibility.

Since I'm not very experienced with nix yet nor do I understand what I have to do to enable CI/cachix/etc.. with nix, I'll experiment in my small repo https://github.com/bolt12/nix-hs-template where maybe I can get a pretty simple and stable scaffolding generator with comments for different scenarios and come back to this issue when I feel more confident!

[o1lo01ol1o]

Worth noting that the next-gen way to handle haskell projects in nix is with https://input-output-hk.github.io/haskell.nix/. This supports configuring projects via `stack` or `cabal` so may be easier to integrate with summoner since there's very few things for the user to decide for the initial configuration.

…

On Sat, Jun 27, 2020 at 11:47 AM Armando Santos ***@***.***> wrote: I'm not very experienced in Nix but I've been looking around tutorials and opinionated guides and found these two: https://discourse.nixos.org/t/nix-haskell-development-2020/6170, https://medium.com/purely-functional/nix-setup-for-haskell-with-ghcide-and-hlint-3e268343efed to work out best. They seem to offer a solution that has the right abstraction granularity and flexibility. Since I'm not very experienced with nix yet nor do I understand what I have to do to enable CI/cachix/etc.. with nix, I'll experiment in my small repo https://github.com/bolt12/nix-hs-template where maybe I can get a pretty simple and stable scaffolding generator with comments for different scenarios and come back to this issue when I feel more confident! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#149 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5DC5LSYZNHNFFT5RYI6GTRYXE33ANCNFSM4FVU47EA> .