* all-cabal-hahses can be a directory
Motivating problem: we want to use the flake.lock for all-cabal-hashes
as a github repository as our revision pin, and then import that to pass
as all-cabal-hashes. To do that we need it to accept a directory rather
than a tarball.
* all-cabal-hashes: add some comments
This is achieved by passing the entire package set to the respective
wrappers and passing the select function as a second attribute. Together
with the new support for callPackage-ing functions this allows for
things like `ghcWithPackages.override { useLLVM = true; } (p: [ … ])`.
To make this possible for `ghcWithHoogle` as well, we need to make the
wrapper a bit more bespoke and inline the hoogle feature as well. The
hoogle wrapper, however, can remain separate and is exposed as
`hoogleWithPackages` additionally, as it can also serve standalone use.
`hoogleLocal` is kept for backwards compatibility (including the old,
suboptimal API), but will inform users about the better alternative via
a warning.
Overrideable functions are possible by wrapping them as functors in an
attribute set first and appending the overrideScope and override
attributes later.
cabal only allows one cabal file per directory and cabal2nix will find
the correct file easily. Thus we don't need to know ahead of time which
cabal file to select. One downside of this is of course that we may
include unnecessary files in subdirectories, which could possibly be
fixed by enforcing depth.
This is a new argument to the Haskell builder's 'shellFor' which allows
the caller to adjust the 'genericBuilderArgs' after they are built.
One immediate application for this is that it allows users to disable
tests, enable benchmarks, etc. for _all_ packages in a given Haskell
package set.
This is often useful when so many of the derivations in the
package set have changed that most of the cache has been invalidated,
and there is no need for the user to run tests on their dependencies,
but they still want these dependencies available in their 'nix-shell'
environment for some package-under-development.
Current, the `cabal2nix` derivation contains both the executable, and a wrapper
that adds `nix` and `nix-prefetch-scripts`, which are required for some
features.
However, when calling `callCabal2nix` to create a derivation from a cabal file
at evaluation time,
these features are not actually used, but the huge closure of
`nix-prefetch-scripts` (which includes multiple vcs, as well as python and perl)
still needs to be fetched.
This commit splits cabal2nix into a lightweight version that is a standalone
static binary (`cabal2nix-unwrapped`), and a wrapper that includes the proper
dependencies in the path for full usage of the command line
utility (`cabal2nix`).
This commit also switches to the default ghc, to reduce the likelyhood of
building a different ghc when calling `callCabal2nix`.
This makes it work like work-on-multi from Reflex Platform. In
particular, rather than making `.env` from `shellFor`, we make `.env`
the primitive, and `shellFor` works by combining together the arguments
of all the packages to `generic-builder` and taking the `.env` of the
resulting mashup-package.
There are 2 benefits of this:
1. The dependency logic is deduplicated. generic builder just concatted
lists, whereas all the envs until now would sieve apart haskell and
system build inputs. Now, they both decide haskell vs system the same
way: according to the argument list and without reflection.
Consistency is good, especially because it mean that if the build
works, the shell is more likely to work.
2. Cross is handled better. For native builds, because the
`ghcWithPackages` calls would shadow, we through both the regular
component (lib, exe, test, bench) haskell deps and Setup.hs haskell
deps in the same `ghcWithPackages` call. But for cross builds we use
`buildPackages.ghcWithPackages` to get the setup deps. This ensures
everything works correctly.
Fix#49818. See the bug for more details.
The work done by haskellSrc2nix is usually lightweight, but needs to
be done each time a cabal file change. This triggers unexpected
network activity for a cache query which results most of the time on a
cache miss.
By disabling substitutes we:
- avoid the, mostly useless, binary cache query
- avoid unexpected network failure when users change a cabal file and
try to rebuild without connectivity.
