Module reexports at the package level

[Roman Cheplyaka]

* Joachim Breitner <mail at joachim-breitner.de> [2013-10-04 11:07:33+0200]
> Hi,
> 
> not sure if this is the right mailing list, as it affects GHC and Cabal,
> but can be used by all library authors. But it is a close fit.
> 
> I?d like to propose Module re-reports on the package level, in order to
> make package reorganization easier on the users. For details, please see
> http://ghc.haskell.org/trac/ghc/wiki/ModuleReexports
> and for discussion, I suggest to use the trac ticket
> http://ghc.haskell.org/trac/ghc/ticket/8407
> 
> Questions are:
>  * Is this useful enough?
>  * Is the design (syntax and semantics) good?

This looks useful ? it could help solve the problem of fine-grained
packages, by providing a means to create meta-packages on which one can
depend. For that it would be also useful to be able to re-export whole
packages, similarly to how we can re-export modules from other modules.

I have two concerns about versioning:

1. Suppose that package-a re-exports Data.Bar from package-b starting
   from package-a-2.0 and package-b-2.0. This means that we shouldn't
   prevent packages to be built with package-a-1.0 and package-b-2.0,
   because that would result in a duplicate module Data.Bar.

   Note that we cannot simply make package-b-2.0 depend on package-a >=2.0,
   because that would result in a recursive dependency. Yet it might be
   useful to tell the dependency solver that these packages are
   incompatible.

2. If package-b has a major API change, it would bump its version, say,
   to 3.0. package-a still has version 2.0, but now it re-exports a
   completely different API.

Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131004/ba19da65/attachment.sig>