Re: [Haskell-cafe] Cabal transitive constraint puzzle

Hi Viktor,


On 05/03/2026 05:54, Viktor Dukhovni wrote:
> Now it turns out that for maximum portability, `mlkem` in turn has a build
> flag `use_crypton` that selects either `crypton`, or (current default) the
> older `cryptonite` library as its dependency.  So the dependen graph is:
> 
> 	tls <- mlkem <- if (use_crypton): crypton else: cryptonite

The general principle (albeit one that is not necessarily widely 
understood or well advertised) is that package APIs should not depend on 
flag assignments, for precisely the reason you outline:

> Since the default flag value in `mlkem` is for now `use_crypton: false`,
> each project that wants to use the (work-in-progress) `tls` appears to need to
> explictly know that `tls` requires a non-default build of `mlkem`, and must
> add the same constraints to its `cabal.project`.
> 
> That transitive explicit configuration requirement is not something one can
> reasonably ask projects that depend on `tls to have to add.

See https://github.com/haskell/cabal/issues/8128 for more discussion of 
this.

So I think the preferable solution is to resolve this at the level of 
`mlkem`, either by forking it into two libraries in order to continue 
supporting both dependencies, or by making a major version bump that 
switches the dependency to `crypton`. The latter seems the most 
reasonable choice given that `cryptonite` is now unmaintained and 
`crypton` is increasingly being adopted across the ecosystem as a 
replacement. Pragmatically it may be helpful to flip the default value 
of the flag but keep it around, so any users inconvenienced by this can 
set the flag manually.

Hope this helps,

Adam

-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England

_______________________________________________
ghc-devs mailing list -- [email protected]
To unsubscribe send an email to [email protected]