darcs patch: Add liftField and maybeField to ParseUti... (and 1 more)

The following two patches add the possibility to install hidden packages.
The first one adds functionality to convert between StanzaFields of different
types and uses that to simplify the parsing and pretty printing code for
package descriptions. The patch should not change the behaviour in any way.
The second patch is quite simple and just adds a flag. It would be much more
involved without the first patch.
What do you think?
regards,
Bertram
Sun Jul 16 19:26:06 CEST 2006 Bertram Felgenhauer

Hi, I'd really appreciate some feedback on this, did anybody look at it? I believe the first patch could help Cabal even if installing packages hidden will not become a (Distribution.Simple) Cabal feature. regards, Bertram Original message: http://www.haskell.org//pipermail/cabal-devel/2006-July/000035.html

Hi, I've discussed the patch with Duncan Coutts. The result is the attached revised patch. Changes: - fix the handling of 'x-' fields - with the previous patch cabal would complain about these as unknown in most contexts - document liftField and maybeField and make their use for converting stanzas more obvious in PackageDescription.hs The second patch is unchanged. A note on installing packages hidden: This should be useful for programs that provide their own plugins or other libraries for internal use. It seems to be simple enough for inclusion in Distribution.Simple. regards, Bertram

On Fri, 2006-07-28 at 04:56 +0200, Bertram Felgenhauer wrote:
Hi,
I've discussed the patch with Duncan Coutts. The result is the attached revised patch. Changes:
- fix the handling of 'x-' fields - with the previous patch cabal would complain about these as unknown in most contexts - document liftField and maybeField and make their use for converting stanzas more obvious in PackageDescription.hs
Thanks. Isaac: I'm happy with both of these patchs if you are. I've also got a slight improvement on the docs for liftField which I'll add if these go in.
The second patch is unchanged. A note on installing packages hidden: This should be useful for programs that provide their own plugins or other libraries for internal use. It seems to be simple enough for inclusion in Distribution.Simple.
Note that it'd also be useful to be able to Cabalise the GHC API package and the old hslibs packages (which makes bundling them with Haskell implementations easier as people who care can easily get at them still). Duncan

Duncan Coutts wrote:
On Fri, 2006-07-28 at 04:56 +0200, Bertram Felgenhauer wrote:
Hi,
I've discussed the patch with Duncan Coutts. The result is the attached revised patch. Changes:
- fix the handling of 'x-' fields - with the previous patch cabal would complain about these as unknown in most contexts - document liftField and maybeField and make their use for converting stanzas more obvious in PackageDescription.hs
Thanks.
Isaac: I'm happy with both of these patchs if you are.
I've also got a slight improvement on the docs for liftField which I'll add if these go in.
Dammit. I've done a lot of refactoring of the parsing stuff, including doing exactly what Bertram did with liftField, but I think I've pushed the changes further. If this patch goes in I have some serious merging to do. I suppose this is my own fault for taking so long with this configuration stuff... Cheers, Simon

On Tue, 2006-08-01 at 12:23 +0100, Simon Marlow wrote:
Duncan Coutts wrote:
Isaac: I'm happy with both of these patchs if you are.
I've also got a slight improvement on the docs for liftField which I'll add if these go in.
Dammit. I've done a lot of refactoring of the parsing stuff, including doing exactly what Bertram did with liftField, but I think I've pushed the changes further. If this patch goes in I have some serious merging to do.
We can hold off, that's no problem. I'm sure it'll be easier to merge in any remaining of Bertram's changes after you push your config stuff than the other way around. Duncan

Duncan Coutts
On Fri, 2006-07-28 at 04:56 +0200, Bertram Felgenhauer wrote:
Hi,
I've discussed the patch with Duncan Coutts. The result is the attached revised patch. Changes:
- fix the handling of 'x-' fields - with the previous patch cabal would complain about these as unknown in most contexts
Right, it shouldn't ever complain / warn about x-fields, right?
- document liftField and maybeField and make their use for converting stanzas more obvious in PackageDescription.hs
Sounds good.
Thanks.
Isaac: I'm happy with both of these patchs if you are.
I've also got a slight improvement on the docs for liftField which I'll add if these go in.
Cool. I'm OK with it, but worried about Simon's patch that does the same thing. Simon, can you tease out that patch in short order and compare it side-by-side w/ Bertram's? Should we just go ahead and apply Bertram's?
The second patch is unchanged. A note on installing packages hidden: This should be useful for programs that provide their own plugins or other libraries for internal use. It seems to be simple enough for inclusion in Distribution.Simple.
Note that it'd also be useful to be able to Cabalise the GHC API package and the old hslibs packages (which makes bundling them with Haskell implementations easier as people who care can easily get at them still).
So this is done w/ a field rather than a flag to configure, but it sounds more like a configure option in most cases, no? Shouldn't this be up to the user more than the package author? It should be a pretty rare package that's meant to be hidden by default. We could always have both a field and a configure flag. peace, isaac

Isaac Jones wrote:
Duncan Coutts
writes: - fix the handling of 'x-' fields - with the previous patch cabal would complain about these as unknown in most contexts
Right, it shouldn't ever complain / warn about x-fields, right?
Indeed. I had missed that parseBInfoField handled those.
Cool. I'm OK with it, but worried about Simon's patch that does the same thing. Simon, can you tease out that patch in short order and compare it side-by-side w/ Bertram's? Should we just go ahead and apply Bertram's?
I'm happy either way. It's not an urgent change, it just seemed to be the right thing to do, in order to add new library stanzas.
So this is done w/ a field rather than a flag to configure, but it sounds more like a configure option in most cases, no? Shouldn't this be up to the user more than the package author? It should be a pretty rare package that's meant to be hidden by default.
I wanted this for lambdabot - it's a stand-alone application, but it's plugin-based; one of the plugin's utilities (runplugs) has an auxillary module (ShowQ) that's arguably not useful for general use. To install it properly, a hidden package seemed to be the right thing. And after refactoring the parsing of the package description adding support for that to Distribution.Simple is a very simple change to Cabal.
We could always have both a field and a configure flag.
That makes sense to me, actually. regards, Bertram

On Tue, 2006-08-01 at 11:26 -0700, Isaac Jones wrote:
Duncan Coutts
writes:
- fix the handling of 'x-' fields - with the previous patch cabal would complain about these as unknown in most contexts
Right, it shouldn't ever complain / warn about x-fields, right?
Right.
Isaac: I'm happy with both of these patchs if you are.
I've also got a slight improvement on the docs for liftField which I'll add if these go in.
Cool. I'm OK with it, but worried about Simon's patch that does the same thing. Simon, can you tease out that patch in short order and compare it side-by-side w/ Bertram's? Should we just go ahead and apply Bertram's?
I'm happy to wait and apply after Simon.
Note that it'd also be useful to be able to Cabalise the GHC API package and the old hslibs packages (which makes bundling them with Haskell implementations easier as people who care can easily get at them still).
So this is done w/ a field rather than a flag to configure, but it sounds more like a configure option in most cases, no? Shouldn't this be up to the user more than the package author?
I don't think so. It is actually the package author who knows if it *must* be installed hidden, eg if it severely pollutes the module namespace like hslibs. It's true that the user might want to make it hidden even if the package author didn't, though at the moment we don't provide the user with the option and no one complains. They can change it using ghc-pkg anyway.
It should be a pretty rare package that's meant to be hidden by default.
That's true, though there are hslibs, the GHC api and lambdabot/Yi/hIDE style plug-in packages. Duncan
participants (4)
-
Bertram Felgenhauer
-
Duncan Coutts
-
Isaac Jones
-
Simon Marlow