Merger?

[dmjio]

Hi @jmitchell, I've been attempting to use stack2nix to generate nix expressions for GHCJS packages. I had trouble trying to specify --compiler ghcjs when stack2nix gets run, since (afaik) the command line arguments to stack2nix aren't the same as what is given to cabal2nix.

This led to some digging into the code and I noticed cabal2nix was being ran as a subprocess, and the generated nix was being parsed by hnix, and the lines related to testHaskellDepends and benchmarkHaskellDepends are being removed from the nix AST in order to satisfy nix during builds (since stack doesn't include test dependencies in the stack list-dependencies output).

In an attempt to support GHCJS packages, I began a small rewrite that simply passes the command line arguments from stack2nix to every invocation of cabal2nix directly (with minor modification). This led to a PR in cabal2nix that exposed the Derivation type from language-nix (NixOS/cabal2nix@cb2265e) which should obviate the need to use hnix in stack2nix.

-- Can remove various sections in `Derivation` in `language-nix` before pretty printing.
 let upd = d' & benchmarkDepends .~ mempty
              & testDepends .~ mempty

https://github.com/dmjio/nixFromStack

Just like stack2nix, The generated nix is in a format that can be used in the same way as hackage-packages.nix.

{ 
  stackPackages = haskellPackages.override { 
    initialPackages = import ./stackage-packages.nix;
  }
}

I'm not sure if nixFromStack can do everything stack2nix can do, but, if possible, was wondering if you'd be interested in combining efforts in some way. Like merge the two code bases, however hairy that process may be.

[domenkozar]

@dmjio thanks for the effort to merge efforts :) I'm very supportive of this since we ought to have one tool that covers the use case of generating Nix expressions from stack2nix.

There are a couple of things going on, including our future improvements we'd like to make to stack2nix which do align with your question.

1. we'd like to support --test flag to stack by stripping out all test dependencies of packages not part of packages directive (minues those as extra-dep)

2. we'd like to move towards using stack types for parsing stack.yaml as rewriting that code and keep it up to date with stack is harder than making sure we compile with a specific version of stack lib.

3. we'd like to support different flags to cabal2nix and stack, but there's no good plan how to do that yet.

To fix 1) and address your issues, this would fall into the category of #5 and I'd like to hear from @jmitchell what he thinks about this plan.

[domenkozar]

@dmjio so to merge code bases we need to evaluate if using Derivation is sufficient enough, because there are many things like prefetch source that cabal2nix does behind the scenes, etc.

[dmjio]

@domenkozar, happy to participate :)

1. Hm, I'm not seeing --test flag to stack, I'm on v1.4.0, am I missing something obvious? In regards to stripping test deps, is this something Derivation can handle? (or does this go back to our "Is Derivation enough?" question -- maybe @jmitchell can give insight)
2. Ah, nixFromStack doesn't attempt to parse the stack.yaml file. It also doesn't attempt to create expressions for extra-deps (I'm not sure if these deps show up in list-dependencies).
3. Yes, this currently sounds difficult to support. One option I can think of is having a config file on disk for the stack parameters stack-params.json, etc, and then just keep stack2nix the same args as cabal2nix.

[domenkozar]

@dmjio

1. It has been just merged into master as part of Enable doCheck on a package using --test option. #35
2. We need to do this to figure out what packages to test/haddock
3. Agreed, CLI might be too limiting :)

[domenkozar]

@dmjio first step towards this direction is in #42

Next up is using Derivation type and then with some smaller changes from your side (like passing compiler) you should be possible to use stack2nix :)

I hope this is useful!

[dmjio]

@domenkozar very nice :) yes, very helpful. Does this mean the dependency on hnix will be removed?

[domenkozar]

@dmjio that's the plan at least, let's see if it works :)

[domenkozar]

@dmjio #75 now uses cabal2nix as a library, really close to getting rid of hnix.

[domenkozar]

@dmjio I'm working now on #81 and then it should be close to what you need.

[dmjio]

@domenkozar Awesome, thanks for your work on this.

[domenkozar]

@dmjio all of your concerns are now addressed in #83

You might just need to add compiler flag.

[dmjio]

@domenkozar, fantastic, I'll give it a go 🍻