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-boun...@haskell.org [mailto:cabal-devel-boun...@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 <ezy...@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@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
