Dev environments

[rvl]

Changes so that this builder can be used to set up dev environments.

• Add a developer shell to the package. This means a nix-shell environment with all the dependencies available, and where ghci is able to import Haskell package dependencies. It can be accessed with the pkgSet.config.hsPkgs.PACKAGE.components.all attribute.

Things to fix:

• Currently only the Haskell package dependencies are put in the shell -- i.e. no system dependencies.
• It might be nice to have an equivalent to ghcWithPackages, but I found that difficult.
• The shell provides only dependencies of the library, exes and tests components. Need to make an all component which combines all components of the package, and base the shell on that.
• The shell does not provide a hoogle index or hoogle command.

[ElvishJerricco]

Can you do the haddock portion in a separate PR?

[ElvishJerricco]

shellAware is a bad paradigm; it makes the resulting expression utterly un-reusable. Rather than having two derivations (one for building and one for shell), I believe the build derivation and the shell derivation should be one and the same. We actually have this already in haskell.nix, but only for per-component derivations. If you nix-shell on one of your components, you'll find the CABAL_CONFIG environment variable set, so that you can use cabal-install to build with your dependencies implicitly.

The issue with this is only that we don't have a way to do the whole package. But I don't think the right answer is to compromise the idea of building and shelling sharing a derivation. Instead, I think we should have an all "component", which when built, configures all components at once, and whose shell therefore provides all dependencies. The CABAL_CONFIG we have actually already handles system dependencies too.

[ElvishJerricco]

Making the all derivation should be pretty easy too. We can just make a new component and mkMerge all the relevant dependency fields. Then we just have to add some logic to tell the configure phase that there's no component argument to Setup configure

[rvl]

OK thanks. I have just started to try and understand this code so please excuse the mistakes.

• The haddock portion is now in builder: Add haddock and hoogle #13
• I have removed shellAware.
• The devEnv attribute is tending towards being all. As it is now, this code can provide a working nix-shell for a test project we have ([DEVOPS-1120] nix-tools based build cardano-shell#11). But it's pretty messy.

Where would the all component be in the package? pkgSet.config.hsPkgs.PACKAGE.components.all ?

In the nix-shell of a library component I have CABAL_CONFIG set to the but it's not working with cabal-install. It looks like setting up the NIX_GHC* variables and wrappers is the most reliable way.

[rvl]

@ElvishJerricco Thanks for the tips. How is the CABAL_CONFIG variable supposed to work?

I added a simple test case in test/tests.sh which runs nix-shell on a component.

The variable is set correctly, but cabal-install doesn't pick it up. Also, how would that work for the non-cabal use case -- for example, if the user would just like to use ghc/ghci?

[angerman]

@rvl could we use https://downloads.haskell.org/~ghc/master/users-guide/packages.html#package-environments for ghc/ghci?

[angerman]

@rvl yea, CABAL_CONFIG seems rather poorly documented :-)
haskell/cabal#5322

[ElvishJerricco]

@rvl I'm surprised cabal-install didn't pick it up. I'll try to experiment with this stuff shortly. I think we need to decide whether we want everything configured for the shell via environment variables, or via wrapper scripts. I loathe wrapper scripts, but unfortunately they seem to work really well.

[rvl]

Hi, yes I agree the wrapper scripts are not ideal. We do need something that works for IOHK projects however. Interested to know the result of your experiments.

[angerman]

Looks good! 👍 for the documentation! Guess we are now set on markdown docs :-)

[ElvishJerricco]

Thanks for the research and documentation on the environment variables. FWIW, ghc-pkg should probably recognize GHC_ENVIRONMENT, so that's probably a GHC issue worth filing. That said, given all the difficulty, it does seem like wrapper scripts are the way to go unfortunately. Given that, we should remove the CABAL_CONFIG variable.

Also, is it possible to avoid aggregating all the package DBs into a mass package DB by using a GHC environment file in the wrapper script? That DB ends up quite large and wasteful on disk, and takes time to create. I'd really like to avoid both long command line argument lists and large wasteful package DBs is environment files enable it.

[ElvishJerricco]

Why concat all the depends when we could just mkMerge the components themselves and have their other attributes like system library deps merged?

[rvl]

Yes, I haven't figured it out yet. In the meantime I have raised #42 for this.

[rvl]

Issues for more remaining work #40, #41, #42.