On Thu, Mar 05, 2026 at 12:48:58PM +0100, Henning Thielemann wrote:
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:
I think that condition is satisfied here: The API of tls is independent from whether mlkem calls crypton or cryponite.
So in principle things should work if `tls` uses `crypton`, and `mlkem` uses `cryptonite`, as Cabal might choose as default.
Sadly, things don't turn out that way. Various functions in the MLKEM API carry type class constraints like `MonadRandom r`, ... where the MonadRandom in question is either the one from `cryptonite` or `crypton`, and so not the same API as far as the type system is concerned. In paricular, when `tls` (using `crypton`) tries to provide a `MonadRandom r`, it is the *wrong* one when `mlkem` is built with `cryptonite` and the code fails to compile. Bottom line, the two variants of `mlkem` don't end up offering the same API (distinct type signatures, that only look the same). So either forking `mlkem` or a major version bump seem to be the sensible choices. I hope Olivier can be convinced to go the version bump route. -- Viktor. 🇺🇦 Слава Україні!