Virtual packages

[Chris Dornan]

Indeed it looks like a mechanism for making multiple packages easier to manage -- rather like RPM provides (from which the terminology is borrowed I think).

It sounds like a really good idea and surely the best way of removing the pressure on providing customization through flags.

Chris


-----Original Message-----
From: cabal-devel-bounces at haskell.org [mailto:cabal-devel-bounces at haskell.org] On Behalf Of Duncan Coutts
Sent: 02 December 2011 11:52
To: Edward Z. Yang
Cc: cabal-devel
Subject: Re: Virtual packages

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

_______________________________________________
cabal-devel mailing list
cabal-devel at haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel