Ticket #654 (new enhancement)

Opened 3 years ago

Last modified 3 years ago

Exposed-packages field

Reported by: jmcarthur Owned by:
Priority: normal Milestone:
Component: Cabal specification Version: HEAD
Severity: normal Keywords:
Cc: Difficulty: unknown
GHC Version: Platform:

Description

Many libraries essentially require the developer to depend not only on the library's package but also some of the library's dependencies. For example, many libraries exposing monad transformers require you to also depend on mtl in order to use them effectively. Another example is GLUT; a package that uses GLUT usually must also depend on at least OpenGL and StateVar? in order to work.

It would also be nice if we had a mechanism for creating metapackages which, if depended on, implicitly represent dependencies on other packages. For example, it might be nice to have a haskell-platform metapackage.

I would like to propose an Exposed-Packages field for .cabal files that would allow libraries to expose packages much like they currently can expose their own modules. There are potentially some issues this could introduce. Namely, what happens of you depend on two such metapackages which both expose different versions of some other package? I haven't decided how I would want Cabal to behave under those circumstances. I'm hoping that some discussion could spark a good idea.

Change History

Changed 3 years ago by duncan

A similar feature would be to allow packages to re-export modules from other packages. This depends on support from the compilers.

Note that the platform is not a good example. We do not want anything depending directly on such meta-packages.

Note: See TracTickets for help on using tickets.