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. 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? Cheers, Edward
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
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@haskell.org [mailto:cabal-devel-bounces@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
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
On 2 December 2011 12:21, 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.
So what are we looking for exactly? The use case I was thinking of previously was something like gtk2hs which is made up of a bunch of packages and during development you typically want to build all of them together. Do we need multiple .cabal files in one dir sharing the same Setup.hs? Or just a local environment which links to each package so you can build them by name easily? Duncan
I thought the idea was to allow a single cabal file to be able to generate multiple packages -- the primary package which shares the name of the cabal file and several 'virtual' packages, each with different permutations of the 'options' flags.
Edward will correct me I am sure if I have misunderstood his intention.
Chris
-----Original Message-----
From: Duncan Coutts [mailto:duncan.coutts@googlemail.com]
Sent: 02 December 2011 13:10
To: Chris Dornan
Cc: Edward Z. Yang; cabal-devel
Subject: Re: Virtual packages
On 2 December 2011 12:21, 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.
So what are we looking for exactly? The use case I was thinking of previously was something like gtk2hs which is made up of a bunch of packages and during development you typically want to build all of them together. Do we need multiple .cabal files in one dir sharing the same Setup.hs? Or just a local environment which links to each package so you can build them by name easily? Duncan
There are two closely related features here (both of which could be useful.) This wasn't helped by me mixing up virtual packages with subpackages (which I think is actually what I wanted.) Here's the relevant quotes: "Provides:" lets you list virtual package names that this package provides. Sometimes there are several different packages that can provide a function, and using packages won't care which one. In that case, each of the packages that provide the function should "provide" a virtual package, and then using packages can list the virtual package name under "Requires:". For example, several different packages might provide "latex"; if you depend on the virtual package "tex(latex)", then users can choose which package to get "latex" from. If you provide virtual packages, you might also want to use the "alternatives" system, but be careful: "alternatives" settings are system-wide, so if multiple users on the same system might want different defaults, don't use the alternatives system. You can find out what a given package provides (both virtual and non-virtual names) by querying "rpm -q --provides PACKAGENAME". So here, something like mtl and transformers both provide some sort of virtual 'monad' package, and you can use one or the other. What I was actually thinking of was subpackages: A spec file can define more than one binary package, e.g., client and server, or runtime and developer packages. If there's a large amount of documentation, it may be split into a NAME-doc subpackage. You will always have one spec file and one source RPM (SRPM), even if there are multiple binary RPMs that they generate. A spec file that produces multiple binary packages still has only one creation process, so there is only one %prep, %build, %check, and %install section that creates all the files for all the packages. The point is you get to share as much of the packaging as possible, but you can tweak specific bits for each subpackage. (When you're packaging upstream files this means you do one build, and then you grab different sets of files. There's not really anything analogous for Cabal, but maybe we could be clever about it. Re Chris's message, I think that misunderstands the proposal a little. If I previously did: cabal install foobar -ffeatureA -ffeatureB You would now do: cabal install foobar cabal install foobar-featureA cabal install foobar-featureB (Not foobar-featureA-featureB... combinatorial explosion of package names) But the package maintainer would still have just foobar.cabal, and 'cabal sdist' would automatically generate the multiple package files. Edward
Hi Edward, Edward Z. Yang [mailto:ezyang@MIT.EDU] sez: You would now do: cabal install foobar cabal install foobar-featureA cabal install foobar-featureB This is what I meant -- I think we are on the same page. Chris -----Original Message----- From: Edward Z. Yang [mailto:ezyang@MIT.EDU] Sent: 02 December 2011 16:31 To: Chris Dornan Cc: Duncan Coutts; cabal-devel Subject: RE: Virtual packages and subpackages There are two closely related features here (both of which could be useful.) This wasn't helped by me mixing up virtual packages with subpackages (which I think is actually what I wanted.) Here's the relevant quotes: "Provides:" lets you list virtual package names that this package provides. Sometimes there are several different packages that can provide a function, and using packages won't care which one. In that case, each of the packages that provide the function should "provide" a virtual package, and then using packages can list the virtual package name under "Requires:". For example, several different packages might provide "latex"; if you depend on the virtual package "tex(latex)", then users can choose which package to get "latex" from. If you provide virtual packages, you might also want to use the "alternatives" system, but be careful: "alternatives" settings are system-wide, so if multiple users on the same system might want different defaults, don't use the alternatives system. You can find out what a given package provides (both virtual and non-virtual names) by querying "rpm -q --provides PACKAGENAME". So here, something like mtl and transformers both provide some sort of virtual 'monad' package, and you can use one or the other. What I was actually thinking of was subpackages: A spec file can define more than one binary package, e.g., client and server, or runtime and developer packages. If there's a large amount of documentation, it may be split into a NAME-doc subpackage. You will always have one spec file and one source RPM (SRPM), even if there are multiple binary RPMs that they generate. A spec file that produces multiple binary packages still has only one creation process, so there is only one %prep, %build, %check, and %install section that creates all the files for all the packages. The point is you get to share as much of the packaging as possible, but you can tweak specific bits for each subpackage. (When you're packaging upstream files this means you do one build, and then you grab different sets of files. There's not really anything analogous for Cabal, but maybe we could be clever about it. Re Chris's message, I think that misunderstands the proposal a little. If I previously did: cabal install foobar -ffeatureA -ffeatureB You would now do: cabal install foobar cabal install foobar-featureA cabal install foobar-featureB (Not foobar-featureA-featureB... combinatorial explosion of package names) But the package maintainer would still have just foobar.cabal, and 'cabal sdist' would automatically generate the multiple package files. Edward
participants (3)
-
Chris Dornan -
Duncan Coutts -
Edward Z. Yang