If the same dependency is listed extra-deps of stack.yaml and it also appears in the packages of the resolver, then it will be output twice in .stack-pkgs.nix.

The error will look like:

error: attribute 'Chart' at /home/rodney/iohk/cardano-wallet/nix/.stack-pkgs.nix:8:9 already defined at /home/rodney/iohk/cardano-wallet/nix/.stack-pkgs.nix:6:9

When building plutus, which depends on doctest, we are greeted with the following

building '/nix/store/dsb4ms3cl8zbmiz75vhs22bzv79ycc1p-doctest-0.16.0.1-lib-doctest.drv'...
unpacking sources
unpacking source archive /nix/store/5bq470x5a3livhakypg1f366cizj5j4n-doctest-0.16.0.1.tar.gz
source root is doctest-0.16.0.1
setting SOURCE_DATE_EPOCH to timestamp 1537720725 of file doctest-0.16.0.1/test/sandbox/cabal.sandbox.config
patching sources
configuring
Configure flags:
--prefix=/nix/store/7pbi41yrc2c7cwxm3hzmwrf8i81lbgdr-doctest-0.16.0.1-lib-doctest lib:doctest --package-db=clear --package-db=/nix/store/78lh5qp3k319g6a7f43givydc89mx0hb-doctest-0.16.0.1-lib-doctest-config/package.conf.d --with-ghc=ghc --with-ghc-pkg=ghc-pkg --with-hsc2hs=hsc2hs --with-gcc=cc --with-ld=ld --with-ar=ar --with-strip=strip --enable-executable-stripping --enable-library-stripping --docdir=/nix/store/0car37r8vml0z0531l13pvwah8bf2ala-doctest-0.16.0.1-lib-doctest-doc/share/doc/doctest
Configuring library for doctest-0.16.0.1..
Loaded package environment from /nix/store/78lh5qp3k319g6a7f43givydc89mx0hb-doctest-0.16.0.1-lib-doctest-config/ghc-environment
clang-5.0: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument]
Error:
    The following packages are broken because other packages they depend on are missing. These broken packages must be rebuilt before they can be used.
installed package ghc-8.4.4 is broken due to missing package directory-1.3.1.5, process-1.6.3.0, bytestring-0.10.8.2, binary-0.8.5.1, time-1.8.0.2, containers-0.5.11.0, filepath-1.4.2, hpc-0.6.0.3, transformers-0.5.5.0, ghc-boot-8.4.4, ghci-8.4.4, unix-2.7.2.2, terminfo-0.4.1.1

builder for '/nix/store/dsb4ms3cl8zbmiz75vhs22bzv79ycc1p-doctest-0.16.0.1-lib-doctest.drv' failed with exit code 1
cannot build derivation '/nix/store/ca251jy00nj1csx9i7f4l4c54waw3xdj-doctest-0.16.0.1-exe-doctest-config.drv': 1 dependencies couldn't be built
building '/nix/store/01kwh9lhghhf8wvvfmp1v1b1csizrkll-resourcet-1.2.2-lib-resourcet-config.drv'...
cannot build derivation '/nix/store/v94kl14rh1gx3fkyrdgn0v7bh67g2f7i-doctest-0.16.0.1-exe-doctest.drv': 1 dependencies couldn't be built

In https://github.com/input-output-hk/haskell.nix/blob/master/docs/user-guide-cabal.md I read the following:

With nix-tools in PATH, we can simply run the following command on a stack project:

But before that user guide talks about cabal.project and as far as I understand normally people use either stack.yaml or cabal.project and there's not much sense to have both of them at the same time.

It would be good if this repo provided one or more ghc versions and a complete working package set (with overrides to make things build), as exists in nixpkgs.

After my success of cross-building for Windows with this setup, I enthusiastically tackled the next task: Building with musl in order to get a fully static Linux executable out.

My current attempt simply passes crossSystem = localLib.systems.examples.musl64 (entropia/tip-toi-reveng@aff912d) and it actually builds a cross-compiling GHC, and some packages (e.g. transformers) build.

But then it tries to build is time, and that fails:

~/projekte/tip-toi-reveng $ nix-build nix -A static-exe
these derivations will be built:
  /nix/store/87ky4yb3x12245rrha081jppi99ds8vq-x86_64-unknown-linux-musl-ghc-8.4.4-with-unordered-containers.drv
  /nix/store/0b3jsm71qn5f35ny952s44y2360qzi71-unordered-containers-0.2.9.0-lib-unordered-containers-x86_64-unknown-linux-musl.drv
  /nix/store/7xaib1dax0f9mkazr3i5bgm361r7fbs2-time-1.8.0.2-lib-time-x86_64-unknown-linux-musl.drv
…
  /nix/store/1phb4ifd1biq108249z0s29k8n2vkdl1-x86_64-unknown-linux-musl-ghc-8.4.4-with-tttool.drv
  /nix/store/9yvh40psh1v9xkic821kw3r7jaxqx8bz-tttool-1.8-exe-tttool-x86_64-unknown-linux-musl.drv
building '/nix/store/7xaib1dax0f9mkazr3i5bgm361r7fbs2-time-1.8.0.2-lib-time-x86_64-unknown-linux-musl.drv'...
unpacking sources
unpacking source archive /nix/store/sn2g8zld91yx9zni0fqwv65dw6vq3afi-time-1.8.0.2.tar.gz
source root is time-1.8.0.2
setting SOURCE_DATE_EPOCH to timestamp 1494705576 of file time-1.8.0.2/changelog.md
patching sources
updateAutotoolsGnuConfigScriptsPhase
configuring
Configure flags:
--prefix=/nix/store/h42hvhrlghb0ri8k64nblrd78fibs26l-time-1.8.0.2-lib-time-x86_64-unknown-linux-musl lib:time --package-db=clear --package-db=/nix/store/8yx0534zb14f5mbl52yk0fjargq76gja-time-1.8.0.2-lib-time-config-x86_64-unknown-linux-musl/package.conf.d --with-ghc=x86_64-unknown-linux-musl-ghc --with-ghc-pkg=x86_64-unknown-linux-musl-ghc-pkg --with-hsc2hs=x86_64-unknown-linux-musl-hsc2hs --with-gcc=x86_64-unknown-linux-musl-cc --with-ld=x86_64-unknown-linux-musl-ld --with-ar=x86_64-unknown-linux-musl-ar --with-strip=x86_64-unknown-linux-musl-strip --enable-executable-stripping --enable-library-stripping --enable-split-sections --enable-static --hsc2hs-option=--cross-compile --hsc2hs-option=--via-asm --configure-option=--host=x86_64-unknown-linux-musl
Configuring library for time-1.8.0.2..
Loaded package environment from /nix/store/8yx0534zb14f5mbl52yk0fjargq76gja-time-1.8.0.2-lib-time-config-x86_64-unknown-linux-musl/ghc-environment
checking for x86_64-unknown-linux-musl-gcc... /nix/store/6mn2kz9109afg48wpm7f121fdfqkwxmn-x86_64-unknown-linux-musl-stage-final-gcc-debug-wrapper-7.3.0/bin/x86_64-unknown-linux-musl-cc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether /nix/store/6mn2kz9109afg48wpm7f121fdfqkwxmn-x86_64-unknown-linux-musl-stage-final-gcc-debug-wrapper-7.3.0/bin/x86_64-unknown-linux-musl-cc accepts -g... yes
checking for /nix/store/6mn2kz9109afg48wpm7f121fdfqkwxmn-x86_64-unknown-linux-musl-stage-final-gcc-debug-wrapper-7.3.0/bin/x86_64-unknown-linux-musl-cc option to accept ISO C89... none needed
checking how to run the C preprocessor... /nix/store/6mn2kz9109afg48wpm7f121fdfqkwxmn-x86_64-unknown-linux-musl-stage-final-gcc-debug-wrapper-7.3.0/bin/x86_64-unknown-linux-musl-cc -E
checking for grep that handles long lines and -e... /nix/store/fr6apsdp46f9m1290gxgfmhfc4rpmcjw-gnugrep-3.1/bin/grep
checking for egrep... /nix/store/fr6apsdp46f9m1290gxgfmhfc4rpmcjw-gnugrep-3.1/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking time.h usability... yes
checking time.h presence... yes
checking for time.h... yes
checking for gmtime_r... yes
checking for localtime_r... yes
checking for clock_gettime... yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking for struct tm.tm_zone... yes
checking whether time.h and sys/time.h may both be included... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking whether altzone is declared... no
configure: creating ./config.status
config.status: creating lib/include/HsTimeConfig.h
building
Preprocessing library for time-1.8.0.2..
hsc2hs: Failed to extract integer
CallStack (from HasCallStack):
  error, called at utils/hsc2hs/CrossCodegen.hs:606:27 in main:CrossCodegen
builder for '/nix/store/7xaib1dax0f9mkazr3i5bgm361r7fbs2-time-1.8.0.2-lib-time-x86_64-unknown-linux-musl.drv' failed with exit code 1
cannot build derivation '/nix/store/yvaaakfwx94knb1b09npcj7l3v760lai-tttool-1.8-exe-tttool-config-x86_64-unknown-linux-musl.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/9yvh40psh1v9xkic821kw3r7jaxqx8bz-tttool-1.8-exe-tttool-x86_64-unknown-linux-musl.drv': 1 dependencies couldn't be built
error: build of '/nix/store/9yvh40psh1v9xkic821kw3r7jaxqx8bz-tttool-1.8-exe-tttool-x86_64-unknown-linux-musl.drv' failed

Not sure what the error message means. But I also wonder why it builds time at all, as this is already contained in the ghc package:

~/projekte/tip-toi-reveng $ find /nix/store/6q8kwqnihrz3mcdaa08465fvwqw319pf-x86_64-unknown-linux-musl-ghc-8.4.4/ -name \*time\*
/nix/store/6q8kwqnihrz3mcdaa08465fvwqw319pf-x86_64-unknown-linux-musl-ghc-8.4.4/lib/x86_64-unknown-linux-musl-ghc-8.4.4/package.conf.d/time-1.8.0.2.conf
/nix/store/6q8kwqnihrz3mcdaa08465fvwqw319pf-x86_64-unknown-linux-musl-ghc-8.4.4/lib/x86_64-unknown-linux-musl-ghc-8.4.4/time-1.8.0.2
/nix/store/6q8kwqnihrz3mcdaa08465fvwqw319pf-x86_64-unknown-linux-musl-ghc-8.4.4/lib/x86_64-unknown-linux-musl-ghc-8.4.4/time-1.8.0.2/libHStime-1.8.0.2_p.a
/nix/store/6q8kwqnihrz3mcdaa08465fvwqw319pf-x86_64-unknown-linux-musl-ghc-8.4.4/lib/x86_64-unknown-linux-musl-ghc-8.4.4/time-1.8.0.2/libHStime-1.8.0.2.a
/nix/store/6q8kwqnihrz3mcdaa08465fvwqw319pf-x86_64-unknown-linux-musl-ghc-8.4.4/lib/x86_64-unknown-linux-musl-ghc-8.4.4/time-1.8.0.2/HStime-1.8.0.2.o
/nix/store/6q8kwqnihrz3mcdaa08465fvwqw319pf-x86_64-unknown-linux-musl-ghc-8.4.4/lib/x86_64-unknown-linux-musl-ghc-8.4.4/directory-1.3.1.5/System/Directory/Internal/C_utimensat.p_hi
/nix/store/6q8kwqnihrz3mcdaa08465fvwqw319pf-x86_64-unknown-linux-musl-ghc-8.4.4/lib/x86_64-unknown-linux-musl-ghc-8.4.4/directory-1.3.1.5/System/Directory/Internal/C_utimensat.hi

I tried to compare it with building Haskell via nixpkgs, so see if this really is an issue with haskell.nix (compared to nixpkgs), but over there no time package is exposed:

~/projekte/tip-toi-reveng/nix-static $ nix-build -A pkgsCross.musl64.haskellPackages.time nixpkgs
error: expression does not evaluate to a derivation (or a set or list of those)

(the time field is present, but null).

So maybe the problem is that time shouldn’t actually be built here?

It seems to take a long time to evaluate components.

• we need some benchmarking of time and space usage.
• especially memory usage because that is a risk for large projects deployed on large nixops networks.

In default.nix I see boot-pkgs:

  # pkg-def's may reference boot packages, but those
  # are not guaranteed to be available on hackage, as
  # it is a manual process.  They might eventually show
  # up much later on hackage; but are not installable
  # anyway. Therefore we just strip them out of the
  # pkg-def's packages.
  boot-pkgs = [ "rts" "ghc" "ghci" "ghc-boot" "ghc-boot-th"
                "ghc-heap" # since ghc 8.6.
              ];

what is supposed to go into this list? The description sounds like it's about wired-in GHC boot packages but in https://github.com/ghc/ghc/blob/master/compiler/basicTypes/Module.hs#L1091-L1098 I see a different module list.

I am playing around with haskell.nix right now, and while I am watching nix-tools build, I wonder if there is no nix cache with the binaries that I could use?

(That would probably also require you to pin nixpkgs to a specific version – but wouldn’t that be good in general, so that users will know which version of nixpkgs this project works best with, in particular with regard to fragile things like cross-compilation?)

If there is a stack.yaml extra-deps entry which is a git repo with multiple subdirs (e.g. cardano-wallet/stack.yaml), then the entire git repo is fetched for each subdirs entry.

It still functions correctly, but is quite slow when you have a big repo like cardano-sl (bloated by stack2nix code) and 14 or so subdirs.

I'm not sure why the fetches aren't cached. Within the stack2nix output it has the fetchgit output, which shows exactly the same store path for each dependency.

If we just use the GHC wrapper script in the builder, there will be no need for a distinction between all and env. They can become the same thing.

After running stack-to-nix, there is still a fair amount of code to add (copy&paste) before you have a working build.

In https://github.com/input-output-hk/haskell.nix/blob/master/docs/user-guide-stack.md I see stack-to-nix invoked as

stack-to-nix -o nix stack.yaml > nix/.stack-pkgs.nix

But the version in the current master shows the following help:

stack-to-nix - a stack to nix converter

Usage: stack-to-nix (-o|--output DIR) [--stack-yaml FILE] [--cache FILE]
  Generate a Nix expression for a Haskell package using Stack

Available options:
  -o,--output DIR          Generate output in DIR
  --stack-yaml FILE        Override project stack.yaml (default: "stack.yaml")
  --cache FILE             Dependency cache
                           file (default: ".stack-to-nix.cache")
  -h,--help                Show this help text

and also it doesn't appear to produce anything to stdout.
Is it some older version maybe?

I've tried building stack-to-nix results for https://github.com/ocramz/xeno and https://github.com/qrilka/xlsx/blob/master/stack-lts-12.yaml - Nix builds for both end up with a result like

qrilka@qdesktop ~/ws/h/xeno/nix $ nix build -f default.nix xeno.components.library
warning: dumping very large path (> 256 MiB); this may run out of memory
error: Nix daemon out of memory
(use '--show-trace' to show detailed location information)

Is it something expected? Probably related to #41

Before OOM nix-daemon consumed over 7G

It seems we are unable to build packages that lack a library component. This came up when building input-output-hk/plutus using the iohk-nix wrapper.

We seem to assume that the library component always exists.

There is no project-to-nix tool for cabal new-style projects.

Unfortunately the whole project parsing logic is in cabal-install, so it can't easily be re-used.

When generating the nix expression from the stack.yaml, we should also generate

let

  stack-pkgs = import ./stack-pkgs.nix;

  overlay = self: super: {
    haskellPackages = (import <stackage>).lts-9_1
      { extraDeps = hsPkgs: (stack-pkgs.extraDeps hsPkgs
                          // stack-pkgs.packages hsPkgs); };
  };

  pkgs = import <nixpkgs> { overlays = [ overlay ]; };

in with pkgs.haskellPackages;
# pkgs.lib.mapAttrs (_: x: callPackage x {})
pkgs.haskellPackages.override {
  overrides = self: super: {
    # FIXME: this doesn't work yet. Overridable logic
    #        is missing.
  };
}

along with it.

That will however break the stdout dump. So Stack2Nix would generate both the pkgset and this expression... Or dump this expression, and generate the current nix-expression in .stack.nix?

The nixpkgs haskell infrastructure provides callCabal2nix which uses import from derivation (IFD).

• It would be good to have a callCabalToNix (however generation of plan.json may be difficult)
• It would also be good to have a callStackToNix

At present, the only component option merged into package.components.all is depends.
Therefore it won't work if there are system libraries, etc.

Need to figure out a way of using mkMerge from the NixOS module system to do this.

Some first attempts are here:
d1a3c56

Having haskell.nix as a Nixpkgs overlay would be neat, and would probably fit better in users' projects.

It should also work standalone.

Provide a nix-tools derivation in haskell.nix.
Then users will not need to clone multiple repos to get started.

Additionally, the processes to regenerate hackage.nix and stackage.nix can be run from the CI of this repo.

Nix builds of https://github.com/haskell/hackage-security from derivations generated by stack-to-nix ends up in a failure:

qrilka@qdesktop ~/ws/h/hackage-security/nix $ nix build -f default.nix hackage-security.components.library
error: attribute 'hsc2hs' missing, at /home/qrilka/ws/h/hackage-security/nix/hackage-security.nix:48:26
(use '--show-trace' to show detailed location information)

README links to https://input-output-hk.github.io/haskell.nix as a full documentation but that URL is not available. If it's a work in progress then it's better to say that explicitly as 404 is not very informative.

• Add a header to all generated files such as "This file was generated by stack-to-nix v0.0".
• Possibly generate a hash of all inputs to stack-to-nix and write the hash into the file.
• Clarify license of generated files.

• Now that we know the builder works, any "compat" code should be removed.
• If there is behaviour that needs to be the same as nixpkgs, then we should as test cases for that.
• The extra dead code makes understanding haskell.nix harder, and is likely to break soon.
• Remove mkPkgSet and just use mkNewPkgSet.

Most nix files should have documentation to say what they do and how they fit in with the rest of the system.

It would be helpful if hackage-to-nix also provided information about the package index which was used.

A Nix file with the following fields:

• Length of ~/.cabal/packages/hackage.haskell.org/01-index.tar.gz in bytes
• Hash of this file according to nix-hash --type sha256 --flat --base32
• UTC date of when script the script was run.

The variable CABAL_CONFIG is not used by the Setup.hs build, nor does it work for running cabal in nix-shells.

Specifically we see messages like:

alex: /nix/store/iq8y91pg75x1j3zb0mchpkxh82y97awh-alex-3.2.4-exe-alex/share/x86_64-linux-ghc-8.4.4/alex-3.2.4-4b3blgwsCz88ZBWTyKoMOl-alex/AlexWrapper-monadUserState-bytestring: openFile: does not exist (No such file or directory)

There seems to be some mismatch between paths nix generates and cabal expects.

Trying out stack-to-nix + nix build on https://github.com/qrilka/xlsx/blob/master/stack-lts-12.yaml resulted in

error: attribute 'ghc843' missing, at /nix/store/15f66d3d57hd018sx781bvdm6cxl87q4-source/modules/hackage.nix:69:15

GHC 8.4.3 is no longer present in nixpkgs, I could use a later snapshot with GHC 8.4.4 in this case but probably this situation should be dealt somehow by nix-tools as well. E.g. printing some error about not available GHC could help (and some advice how to make it available)

It would be good to have some overview of how the pieces fit together. This would be for nix developers who would like to contribute to the maintenance and improvement of this system.

For example:

• the difference between config.packages vs config.hsPkgs.
• more description of what each module does in new-package-set.
• what are hackage.nix and stackage.nix?
• what are nix-tools?
• ...

There is a usability problem/bug with the stack-to-nix cache file.

Firstly, users don't understand what it is, and assume that this file is the real product of stack-to-nix (e.g. cardano-foundation/cardano-wallet@17485e1).

Secondly, after running stack-to-nix and then git commit -a -m "regenerate stuff", there may have been new .stack.nix/*.nix files that are not checked in to git and then lost.

Thirdly, after the .nix file is lost, but .stack-to-nix.cache is updated with an entry, the necessary file will never again be generated, and stack-to-nix will not work properly until the cache file is removed.

There need to be additional checks that cache entries are valid before using them.

The .stack-to-nix.cache file only ever grows. Old entries should be cleaned up.

It will be difficult to maintain if there aren't any tests.

Golden tests will be easiest probably.

stack2nix is quite easy to use.

• PR input-output-hk/nix-tools#29
• Add an option for single-file output (rather than a directory of files), just like stack2nix.
• No need to implement stack2nix with URL to a stack file. I don't think anyone wants that.

Currently https://input-output-hk.github.io/haskell.nix/user-guide/ is phrased with nix-tools already installed, and links to https://github.com/input-output-hk/nix-tools. There, installation is recommended via

nix-build -A nix-tools-all-execs

but the README at https://github.com/input-output-hk/haskell.nix recommends

nix build -f https://github.com/input-output-hk/haskell.nix/archive/master.tar.gz nix-tools -o nt

It is unclear if there is a difference, and when to best use which, so ideally https://input-output-hk.github.io/haskell.nix/user-guide/#user-guide would just give canonical instructions.

At least one of the builder tests should be cross-compiled for Windows or something like that.
It's quite easy to break people's cross builds without noticing.

stackage.nix is almost entirely auto-generated, but if it were organised into subdirectories then the main directory listing wouldn't break github.

I propose:

• stackage.nix/
  • lts/
    • ...
    • lts-11.19.nix
    • ...
  • nightly/
    • ...
    • nightly-2019-02-09.nix
    • ...
  • README.org
  • ltss.nix
  • nightlies.nix
  • default.nix
  • lts-haskell (submodule)
  • stackage-nightly (submodule)

We now have a few tests of the builder code. It would be good to have more in order to make this project maintainable. We should add some form of CI to run the tests.

Chart-cairo is one of our dependencies.
It requires gtk2hs to build.

hsc2hs has an --via-asm flag. That will cause it to use its AT&T Asm parser to figure out the size of constants, ... once essential issue here is that we generate a single c file for each constant. It would be better if we generated all constants (with some identification flag) in one file, and only parsed that file. I believe this would give hsc2hs a considerable performance boost.

This is especially pronounced if a windows cross compiler builds the Win32 package which has lots of hsc2hs usage.

From @ElvishJerricco

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 if environment files enable it.

If there is a package with no exposed modules in its library component, then the haddock phase of the build will fail.

This can be seen when building packages such as bytestring-builder. The error message is:

haddock: No input file(s).

It could be annoying for users if multiple dependencies fail to build and require setting doHaddock = false.

Adjust cabal-to-nix and/or the component builder so that doHaddock can be automatically disabled if necessary.

I was trying out building some Stack packages with nix-tools but got failed. E.g. for the current Stack's master I get

error: attribute 'ghc822' missing, at /nix/store/15f66d3d57hd018sx781bvdm6cxl87q4-source/default.nix:82:21

and it looks like that line adds special patches but at https://github.com/input-output-hk/haskell.nix/tree/master/patches the oldest GHC version looks to be 8.4.1
If older versions are not supported then it makes sense to exclude corresponding Stackage snaphots as well.
Also it would be great if error from Nix were more descriptive.

We currently build the Setup.hs with the host compiler. This works, but it would be nice if we could selectively augment the package database that Setup.hs is built with. That is e.g. allow to specify a newer Cabal version to build the Setup.hs with.

If we could do this, we would not need to patch Cabal in GHC, but could just patch it outside and have Setup.hs built against that Cabal.

--
This is technically a nix-tools issue. But as we are collecting stuff here, I post it here.

Ordinary nixpkgs overlays are functions of 2 parameters as it's described in the manual and https://github.com/input-output-hk/haskell.nix/blob/master/docs/user-guide.md also talks about overlays passed as pkg-def-overlays. Only after reading haskell.nix sources it became clear that I should put either packages or function over hackage.
It would be good to either rename this attribute or at least update documentation about what's expected as its contents.

Since merging input-output-hk/nix-tools#31, we now have two copies of the caching logic. This should be externalized into a library! If we use a sub library to externalize the caching logic, we would automatically get an implicit test case as nix-tools would exercise the sub-library logic on it self.

There are messages about haddock files missing or something like that.
It's not actually haddock. Possibly it's coming from ghc-pkg.

There is no manual like what exists for nixpkgs haskell infrastructure.

• The manual should contain documentation for each of the use cases.
• It should show how and when to update the haskell.nix, hackage.nix and stackage.nix pins for client projects.
• Document the pkgSet structure.
• Document the mapping from derivation name to attribute in pkgSet structure.