Git annex provides a login shell for restricted access:
https://git-annex.branchable.com/git-annex-shell/
This was not exposed with `passthru.shellPath` before, so you could
not set a user's shell to `haskellPackages.git-annex` declaratively
before this change.
I've tried to be conservative and only clean up things that broke eval
which in most cases had to do with uses of versioned packages that have
become the default in Stackage Nightly now. There's probably still
potential for cleaning up some additional workarounds and likely there
are still a lot of new workarounds to be found once we know about the
build failures.
Also note that clean eval only means that nix-env doesn't fail.
Notes:
* HLS now lacks the stylish-haskell and britanny plugins by default,
since they don't support GHC 9.0.2. We'll need to re-enable them
for GHC < 9.0.2
* A lot of uses of hspec 2.9.* can probably be removed, as 2.8.* which
is used in Stackage Nightly is new enough for most packages.
utc has been unmaintained for a while now (last commit was 2016). We
duct taped it to keep it compiling, but now System.Clock is no longer
importable safely. I think it's time to lay it to rest, as it also has
some severe bugs causing it to produce incorrect results.
It's a bit sad, as I think it would be the better time library. Maybe
I'll try to become the hackage maintainer at some point [1].
[1]: https://github.com/lpeterse/haskell-utc/issues/8#issuecomment-786653135
We could also be using fetchFromGithub but the repo looks stale enough that it
doesn't really matter, plus the upper bounds for almost all the dependencies
doesn't exist anymore.
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.
