* This adds more logic for the cabalProjectToNix idf
That is, something like this:
```
nix-build --expr 'with import ./. {}; callCabalProjectToNix { index-state = "2019-04-30T00:00:00Z"; src = /some/path; }'
```
should produce something that can be build with mkCabalProjectPkgSet.
* Make sure the hackageTarball's store path doesn't change
previously the fetchurl would produce a different store path each
and every time as hackage's index is a moving target. With this
impurity setup, we can ignore this.
* Fix test
* Proper name
* Re-enable test
* Allow to parameterize over the `system` for the test default.nix
* Copy instead of link for ifds.
This makes me really sad.
This would be useful if the project needs to stay with an old version
of haskell.nix but use recent version of hackage.nix/stackage.nix.
Normally latest haskell.nix and latest hackage/stackage are best.
Providing hackage and stackage here simplifies usage of the new
Haskell Infrastructure.
With this change, the user doesn't need to specify revisions of the
external repos, or update them.
Basically, with hackage.nix and stackage.nix, the latest version is
always best, because snapshots and package versions are added on
top. So there is no need for users to choose a revision.
Also add mkStackPkgSet which is a shortcut for building stack
projects.
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.
