Compatibility with hashable-1.4

[sjakobi]

See https://hackage.haskell.org/package/hashable-1.4.0.0/changelog.

In v0.14.0.2 I get

src/Nix/Expr/Types.hs:143:23: error:
    • No instance for (Eq1 Params)
        arising from the 'deriving' clause of a data type declaration
      Possible fix:
        use a standalone 'deriving instance' declaration,
          so you can specify the instance context yourself
    • When deriving the instance for (Hashable1 Params)
    |
143 |     , Show, Hashable, Hashable1
    |                       ^^^^^^^^^

when I use --allow-newer=hnix:hashable, so this will require code changes.

[Anton-Latukha]

Noted.

Would release the next 0.14 support version & ramp up to 1.6

[Anton-Latukha]

The solution there is simple.

hashable now requires Eq1 a => Hashable1 a (Eq1 is required).

hnix uses deriving-compat TH deriving for {Show,Read,Ord,Eq}{1,2} instances. Haskell code is sensitive to the order of TH code in the source files. Hashable1 requires Eq1 before it was $(deriveEq1 ''...) by TH. So the solution is to put Hashable1 as standalone deriving after TH deriving.

[Anton-Latukha]

The next station is relude supporting new hashable.

[Anton-Latukha]

Seems like the problem goes deeper. For old hashable: ghc-bignum has 1.0 & 1.2 published, but GHC 9.0 boots from 1.1 & 9.2 boots from 1.2, so solver under GHC 9.0 wants 1.1 which is not published to Hackage: https://github.com/kowainik/relude/issues/394#issuecomment-1006486967

I do not know the cause of it.

[sjakobi]

Boot libraries are often uploaded to Hackage with some delay. In this case, I've requested the upload of ghc-bignum-1.1 in https://gitlab.haskell.org/ghc/ghc/-/issues/19632#note_400751.

If you're struggling to work with GHC 9.0.2, which is still very fresh, I'd recommend using GHC 8.10 for now.

[Anton-Latukha]

9.0 is tested in the CI. hnix currently tests 8.8 & 9.0. And freezing the GHC/Hackage would require a level of complexity & fiddling with setup. Freezing the GHC is simple, the freezing of Hackage index-state by use of .project may be a worthwhile effort.

[Anton-Latukha]

Correcting myself. The next step of the check showed that particularly the old hashable 1.3.5 to which solver arrived - does not support ghc-bignum 1.1, it supports 1.2 but 1.1 was skipped during the dependency description updated because of the proper policy that package bounds should not include unreleased major numbers.

In HLS stumbled on alike situation & opened https://github.com/clash-lang/ghc-typelits-natnormalise/issues/60.

[sjakobi]

@Anton-Latukha Note that hashable-1.3.5.0 was revised to support ghc-bignum-1.1 and GHC 9.0.2: https://hackage.haskell.org/package/hashable-1.3.5.0/revisions/

[Anton-Latukha]

Uploaded support release hnix-0.14.0.6. It allows new hashable, but relude upstream is still to allow it, thou seems its upstream roadblocks are resolved.

[sjakobi]

@Anton-Latukha hnix-0.14.0.6 fails to build with hashable >= 1.4 and --allow-newer=relude:hashable:

$ cabal install hnix-0.14.0.6 --constraint 'hashable >= 1.4' --allow-newer=relude:hashable
Resolving dependencies...
Build profile: -w ghc-8.10.7 -O1
<...>
src/Nix/Expr/Types.hs:143:23: error:
    • No instance for (Eq1 Params)
        arising from the 'deriving' clause of a data type declaration
      Possible fix:
        use a standalone 'deriving instance' declaration,
          so you can specify the instance context yourself
    • When deriving the instance for (Hashable1 Params)
    |
143 |     , Show, Hashable, Hashable1
    |                       ^^^^^^^^^
cabal: Failed to build hnix-0.14.0.6 (which is required by exe:hnix from
hnix-0.14.0.6). See the build log above for details.

Could you revise the upper bound on hashable?

BTW, I'd really encourage you to use cabal to check compatibility questions like this one.

[Anton-Latukha]

Hmm... it was building with 1.14.0.2 under multiple GHCs locally :thinking:.

I actually more than triple-chacked it. Under 8.10.7, 9.0.1, 9.0.2.

Because I know that the hashing required the instance inference changes & ordering with TH entries in the mainline. But in 0.14 branch - cabal after updating the bound was happy to build with it. --allow-newer=hashable also passed happy under several GHCs.

So I even could not type check it, it continuously returned the successful build.

I thought that cabal may infer the need of rebuild wrong, but kind of refuted it, since the build passed under several GHCs & conditions, tooling was happy to build hashable 1.14.0.2 dep and do early cutoff after it with positive status.

[Anton-Latukha]

Well, bummer.

[Anton-Latukha]

Sorry for bothering you.

[Anton-Latukha]

I distinctly remember local builds passing with hashable 1.14.0.2.

[sjakobi]

Maybe you were testing with the wrong version constraint then. The new version of hashable is 1.4, not 0.14.

[Anton-Latukha]

Well, that is probably my typo. The hnix version is 0.14.0, the hashable is 1.14.0, there is also hashing and other details like cabal --allow-never hashable and cabal --allow-never=hashable. I better just fix this.

[Anton-Latukha]

Another day, another release.

Generating haddocks for upload now.

[sjakobi]

Thanks! v0.14.0.7 works for me. :)

[Anton-Latukha]

Well, sorry. Have a nice evening.

[Anton-Latukha]

Well, prepare for the soon arriving 0.16 :rofl:.

I hope I would manage to release it with fewer dots than 0.14.