We have been using `readFile` and `fromJSON` to read a `.json` a 60MB .json file. This change puts the information contained in the json file into `.nix` files that are imported when needed (rather than all at once). This seems to save around 1s at eval time.
Tested with:
```
time nix-instantiate -E '(import ./. {}).pkgs-unstable.haskell-nix.tool "ghc8107" "hello" {}'
time nix-instantiate -E '(import ./. {}).pkgs-unstable.haskell-nix.tool "ghc8107" "haskell-language-server" {}'
```
See also https://github.com/input-output-hk/nix-tools/pull/118
Currently the haskell.nix overlays replace `haskell` and
`haskellPackages` in the root of pkgs with versions that have just a
fraction of what nixpkgs provides.
Although `haskell-nix.haskellPackages` could be used to provide a much
more complete set there are subtle differences that are likely to cause
issues (and nixpkgs has patches for many haskell packages).
To make it possible for haskell.nix and nixpkgs haskell to coexist,
we need to move the remaining parts of haskell.nix outside of the
`haskell-nix` attribute into `haskell-nix`.
```
ghc -> haskell-nix.ghc
cabal-install -> haskell-nix.cabal-install
haskell.compiler -> haskell-nix.compiler
haskell.packages -> haskell-nix.packages
bootstrap.haskell.compiler -> haskell-nix.bootstrap.compiler
bootstrap.haskell.packages -> haskell-nix.bootstrap.packages
```
The following `haskellPackages` have been removed and instead the
nixpkgs versions will now be in `haskellPackages`. User code should
be updated if the nixpkgs versions are not desired:
```
haskellPackages.hoogle
-> haskell-nix.haskellPackages.hoogle.components.exes.hoogle
haskellPackages.happy
-> haskell-nix.haskellPackages.happy.components.exes.happy
haskellPackages.alex
-> haskell-nix.haskellPackages.alex.components.exes.alex;
```
Guard code has been added to overlays/defaults.nix to prevent us
inadvertently depending on the nixpkgs `haskell` or `haskellPackages`
inside the haskell.nix code base.
* Add a custom error message for a missing stack resolver
* Make mkCabalProjectPkgSet robust to missing Hackage patches
* Add error for component prefix lookup
* Add a custom error for a missing GHC
When using stackage as a baseline via stack-to-nix, we usually
assume stackage to be the base, and some augemnetation via
extra-dependencies and packages in the `stack.yaml` file.
To achive this we extend the package-set builder by allowing
a list of additional sets of package to speicied. These are then
folded onto the base package set.
As stackage seems to define the `rts` package as well, we force
`rts-1.0` to be null ontop of our hackage database. As of
today (November 7th, 2018) there is no way of building the rts outside
of GHC; and as such no way to ever get the rts package onto hackage.
Once this package is *on* hackage, we can drop the hack.
Hamish Mackenzie
John A. Lotoski
Hamish Mackenzie
Michael Peyton Jones
Moritz Angermann
Will Fancher