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]
