Virtual packages

[Duncan Coutts]

On 2 December 2011 07:19, Edward Z. Yang <ezyang at mit.edu> wrote:
> Hello folks,
>
> I was thinking a little about how build flags that modify functionality
> are harmful for dependency resolution (pandoc and xmobar, I'm glaring at you),
> but authors will still use this feature because it's a lot easier than maintaining
> a bunch of separate packages for each different flag.

Yes, when designing the flags mechanism we explicitly decided not to
allow depending on package +/- flags because this is impossible to
translate into native distro packages. Therefore, packages are not
allowed to change their interface based on flags. If they do so
anyway, that's their own fault. We could however consider trying to
enforce this more strictly.

> It suddenly struck me, then, that what we actually needed was a mechanism
> not unlike what you see in traditional package managers, where a single Cabal
> file can specify multiple packages.  pandoc.cabal might define 'pandoc'
> and 'pandoc-highlighting', and pandoc-highlighting can have different
> build dependencies, modules, etc.  Module writers still need to arrange their
> APIs so that the extra functionality should be separable, but I don't see
> this as being too much of a problem.  Mix-and-matching flags can be achieved
> by simply picking the extra virtual models as dependencies as necessary.
>
> What do you think?

How is that different from multiple packages? Do we just need better
tools for working with multiple related packages?

Duncan