Packages within a package

[John D. Ramsdell]

Henning Thielemann <lemming at henning-thielemann.de> writes:

> Having sub-packages is also one thing I need, but your example is
> one where I think that sub-packages are the wrong
> approach. Uploading the imported package (the binary decision
> diagram one) to hackage.haskell.org and including it (in the
> symbolic model checker) with the concrete version number is the
> better way.

The developer in my hypothetical symbolic model checker example
decided to include a specific version of a binary decision diagram
package within his system, just as the developers of NuSMV decided to
incorporate CUDD into their distribution.  You cannot second guess
his/her decision.  You should assume the developer knows about
hackage.haskell.org, and chose not to use it, say for legal reasons.

I cannot help but observe that I have received several answers on this
list that show a distrust in wishes of Cabal users.  Instead of
addressing the needs given by the question, some of the answers are of
the form: you shouldn't be doing that, followed by a tortured method
for cramming the problem into the existing set of abstractions.  The
point of the questions is to get people to reassess the set of
abstractions.

> > Recently, when I discovered there is no direct support for linking the
> > executables in a package with the library it defines,
> 
> You can define executables in a package which are automatically build -
> however Cabal will recompile the imported modules instead of using the
> compiled ones from the library part.

In a previous note, I showed how to get around this deficiency in
Cabal using hook functions.  With more use, I have since refined the
code I sent to the list.  If anyone wants the improved version, I'll
send it to you.  By the way, I think it is a tribute to the Cabal
design, and the hook design in particular, that it was so easy for me
to fix the problem using public interfaces, and just a small amount of
code and effort.

> > I wondered why the advice was to separate the library and the
> > executables into two packages even though both are meant to be
> > used and distributed as a unit.
> 
> As far as I know the future plan is to split Cabal projects into
> library and executable parts and then to allow also multiple library
> parts. This way you could provide parts for special applications or
> different operating systems.

Please do not drop support for packaging a library with executables
build on top of the library.  The hook function hack noted above
allows me to make it so that Cabal serves my needs, and one package
can be used to distribute my system as a single unit.

> > Does Cabal not support things like packages within a package
> > simply because Haskell libraries currently are not complex enough
> > to require such a feature, or is there a guiding design principle
> > with which these features are incompatible?
> 
> It was requested several times but it seems not to be designed and
> implemented so easily.

I bet it's easier than you think.  You just have to dynamically
generate package configuration files, just as I did to resolve my
linking problem.

John