haskellmoduledependencieslibrariescabal

Is there a fundamental reason why only one library can be exposed from a package?


From the latest version of the doc I read

A package can have no more than one unnamed library.

Why does this limitation exist? Is it just a "temporary" limitation that could be lifted sooner or later, or is it "necessary" to Haskell's build model-or-something?


From that limitation I understand that I can have at most one library stanza in my .cabal file, which in turn means that if I want multiple exposed-moduless from this library they must share build-depends.

What options do I have if I want to avoid multiple exposed modules from sharing all their dependencies?

The only thing I can think of, is that I could have each module be exposed by its own package.

Now, if the sets of dependencies of the two modules to be exposed have no intersection (say module A depends on module A2, and module B depends on module B2), that would be fine, and I could also ask myself "why have I put those two modules in the same package in the first place, if they have nothing to do with each other? Just create package A exposing A with A2 being internal library with its own dependencies, ..."

However, if the intersection is not null (say module A depends on A2 and C, and module B depends on B2 and C, with A2, B2, C being implementation details), then, it does make sense for them to share some dependencies. But once I've made A and B separate packages, then also they're common dependencies have to be (each single one or all of them together) a standalone package. Which means... that I'd have to publish and expose 3 or more packages, even if I only meant to expose two.


What is the recommended way to operate in this case?


Solution

  • The answer is here, I was just looking at some old version of the doc.

    Here's what the new has to say

    Before version 3.0 of the Cabal specification, all sublibraries were internal libraries. Before version 2.0, a package could not include sublibraries.