Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Exposed-packages field #647

Open
bos opened this Issue · 1 comment

2 participants

@bos
Owner

(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
Owner

(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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.