On 2 December 2011 07:19, Edward Z. Yang
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