* Remove unused (and broken) test files
* Make default.nix expose pinned nixpkgs
Also make `nixpkgs/default.nix` just an attribute set of sources.
This is simpler, and consistent with what e.g. `niv` does.
* Add backwards compatibility shim, and version argument to allow evolution in future
* Fix some missed things
* Fix and improve quickstart
* Updated the haskell.nix imports to overlay style
Some of the examples in the documentation were still passing an empty
set to the haskell.nix imports but this is no longer valid because the
import now results in a set rather than a function.
* Fix overlay imports in docs
Import an overlayed nixpkgs rather than just the overlay.
Thanks to angerman for noticing this error.
This change adds a `materialized` argument to the functions that
generate nix files with `plan-to-nix` and `stack-to-nix`.
* Provides `builtins.trace` messages with pointers on how to do so.
* Includes a `checkMaterialized` option that can be used
to verify the materialized files.
* Documents how to script updates with `plan-nix` or `stack-nix`.
* Outputs warnings if materialized files are used without hash
(or without an `index-state` for cabal projects).
* Provides materialized nix files for `alex`, `happy` and `hscolour`
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.
The Overlays branch
This is a major reorganization in how haskell.nix is used, and marks our 1.0 release.
The branch doesn't build due to numerous issues that we believe to be with the CI
and not this branch. We expect only very minor adjustments prior to calling this the
official 1.0 release.
* Move iohk-nix patches into haskell.nix
This moves the customizations we did in iohk-nix
into haskell.nix via overlays and config.
Add bootPkgs logic
this moves the nuking of bootPkgs where it belongs. This should eventually still be
removed and replaced by a proper solution, that doesn't require the nuking of
bootPkgs.
Allow us to bootstrap binary ghcs and a cabal-install
With this we can do the following:
```
$ nix repl compiler/old-ghc-nix
nix-repl> :b (let pkgs = import <nixpkgs> {}; in with import ./. {}; import ./compiler/bootstrap/cabal-install.nix { inherit (pkgs) fetchurl stdenv zlib; inherit hackage
; ghc = ghc844; src = pkgs.fetchurl { url = "https://github.com/haskell/cabal/archive/Cabal-v3.0.0.0-rc3.tar.gz"; sha256 = "1zl2mgg8307ykq3v8nmafc6zdhhj1cw7w8ffpap16dsm6
5lbnx33"; }; })
```
which wile it may look daunting, will allow us to bootstrap a
cabal-install with a ghc. From that point onwards, we should be able to
build any hackage package via haskell.nix.
Pass through cabal-install version
Better threading of arguments.
Add bootstrap overlay
Allow alex + happy to be built
This still has a wart: we need nix-tools, and for that we use the ghc865 from
nixpkgs. Ideally we'd build nix-tools against a specific ghc, but then
we'd need a build expression for that.
Make ghcjs work
Building something like this:
```
nix build '(with import ./. { nixpkgs = ../nixpkgs; nixpkgsArgs = { crossSystem = { config = "js-unknown-ghcjs"; }; }; }; (haskell-nix.hackage-package { name = "hello"; version = "1.0.0.2"; })).components.exes.hello'
```
will now work. Assuming `nixpkgs` has been appropriately patched to support the `js-unknown-ghcjs` triple.
Also: this will need an additional `Cabal` patch, to make `Cabal` understand what it needs to do with: `dist/build/hello/hello: copyFile: does not exist (No such file or directory)`
It needs to learn that `dist/build/hello/hello.jsexe` is what it wants to copy and that that is a directory. Luckily we do have some code in Cabal already that does this for `.exe` on windows.
Build `js-unknown-ghcjs` packages with haskell.nix
Using the following expression:
```
with import ./. { nixpkgs = ../nixpkgs; nixpkgsArgs = { crossSystem = { config = "js-unknown-ghcjs"; }; }; };
let Cabal = buildPackages.haskell-nix.hackage-package {
name = "Cabal"; version = "2.4.1.0";
modules = [
{ packages.Cabal.patches = [ ./Cabal-install-folder.diff ]; }
];
}; in
(haskell-nix.hackage-package {
name = "hello"; version = "1.0.0.2";
modules = [
({config, ... }:{ packages.hello.package.setup-depends = [ Cabal ]; })
];}).components.exes.hello
```
in a `test.nix` file. And running
```
nix build -f ./test.nix
```
on it, will produce
```
./result
├── bin
│ └── hello.jsexe
│ ├── all.js
│ ├── all.js.externs
│ ├── index.html
│ ├── lib.js
│ ├── manifest.webapp
│ ├── out.frefs.js
│ ├── out.frefs.json
│ ├── out.js
│ ├── out.stats
│ ├── rts.js
│ └── runmain.js
└── share
└── doc
└── x86_64-linux-ghc-8.6.5
└── hello-1.0.0.2
└── LICENSE
6 directories, 12 files
```
Project flags (from stack.yaml and plan.json) are exported in a modules attribute by stack-to-nix and plan-to-nix, but are not currently used. This change updates `mkStackPkgSet` and `mkCabalProjectPkgSet` so that the modules attribute is used (if present) and includes tests to check they are.
This commit makes `stdenv.lib.mkOverride` necessary for setting flags in `mkCabalProjectPkgSet` modules, however it also means that you can set them in `cabal.project` instead (see #254).
- Dev note about nixpkgs pin
- More information about selecting a GHC version for cabal projects
- A little bit more information about cross compiling, but this is still incomplete.
Hamish Mackenzie
Michael Peyton Jones
Kris Jenkins
Toon Nolten
Moritz Angermann
Rodney Lorrimar
Stefan Matting
Aycan iRiCAN