Exposed-packages field #647

bos opened this Issue May 24, 2012 · 3 comments


None yet

3 participants

bos commented May 24, 2012

(Imported from Trac #654, reported by @jmcarthur on 2010-04-07)

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.

bos commented May 24, 2012

(Imported comment by @dcoutts on 2010-04-07)

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.

@ttuegel ttuegel added this to the _|_ milestone Apr 23, 2015

This is wishlist at best and with no activity since mid-2010, I propose it just be closed.

ttuegel commented Mar 7, 2016

Agreed. Also, the ongoing Backpack work addresses this.

@ttuegel ttuegel closed this Mar 7, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment