Proposed ghc-pkg and cabal feature - right list?

[Axel Simon]

I'm replying to Simon M. and myself, as should have sent my first  
reply to the ghc users list, I guess.

On 14.03.2010, at 10:54, Axel Simon wrote:

> Hi Dan,
>
> I reply to libraries, I think that's the right list for Cabal.
>
> On 13.03.2010, at 21:39, Dan Knapp wrote:
>
>> There doesn't seem to be a mailing list for Cabal itself, so I'm
>> posting here.  I came up with an idea for a small feature that I
>> believe would make a useful addition to ghc-pkg and Cabal.  I'm
>> willing to implement it myself, but I have had some previous
>> experiences with other projects where I did some work and then the
>> maintainers said "sorry, not interested", so I want to gauge interest
>> before I start.  Who should I talk to?
>>
>> The feature itself is this:  Arbitrary key-value pairs in Cabal
>> package files and the installed-package database.  The use-case is  
>> for
>> an application supporting plugins to discover installed plugins
>> compatible with it, interrogating these fields through the GHC API.
>
> For Gtk2Hs I would like to have a similar feature. Gtk2Hs is a  
> wrapper for Gtk+. It evolves on its own (for which the package has a  
> version number) but it may wrap different versions of Gtk+.
> I think people using Gtk2Hs need to be able to conditionally compile  
> certain code fragments, depending on which Gtk+ version Gtk2Hs  
> wraps. However, I had something simpler in mind than providing any  
> kind of key,value pairs: I would like to "export" certain Cabal  
> flags into the package, which could be as easy as specifying:
>
> Flag gtk_2_2
>  Description:  Build objects for Gtk+ version 2.2.
>  Exported: True
>
> Flag gtk_2_4
>  Description:  Build objects for Gtk+ version 2.4.
>  Exported: True
>
> Flag gtk_2_6
>  Description:  Build objects for Gtk+ version 2.6.
>  Exported: True
>
> where the 'Exported' would mean that this flag should be added to  
> the package data base. A package would then be
>
> gtk-0.10.4{gtk_2_2,gtk_2_4}
>
> if the first two flags would be set by Cabal. A package could then  
> depend on gtk-0.10.4 in which certain flags are set. Moreover, I  
> would then want cabal to compile a users package with -Dgtk_2_2 - 
> Dgtk_2_4 so the user can use CPP to conditionally compile code.
>
> You suggestion of using arbitrary key,value pairs is more general  
> and needs more thought. You would have to extend Cabal quite a bit  
> whereas my proposal is more lightweight in that it can build on top  
> of Cabal's Boolean flags. May I ask:
>
> - could you express your package properties using Boolean flags  
> (which are set by Cabal automatically)?
> - if not, could you not express your plug-in concept using several  
> packages?
>
> Cheers,
> Axel.
>
>
>> For example, my content-management system FruitTart could enumerate
>> the list of installed packages looking for packages which export a
>> field "fruit-tart-plugin-interface-version" with a numeric value
>> matching the interface version it's expecting.

I'm not quite sure I understand the use case here. Are you saying you  
want to writing something within Cabal? Or do you want to use the  
Cabal API to find out if a certain package is available?

If you're talking about dynamic plug-ins then I assume it must be the  
latter. Besides the technical difficulty of loading a GHC package  
dynamically (that I don't know anything about), what prevents you from  
looking for a package that contains just the plug in?

On 15.03.2010, at 16:38, Simon Marlow wrote:
>>
>
> My first thought was "hmm, there must be another way to do that",  
> but I can't think of one, or at least a good one.
>
> Perhaps having arbitrary key-value pairs in the package database  
> would be a good thing.  It would help us to avoid breaking things  
> when we need to change the format, for one thing.  We could start  
> using key-values for new fields rather than adding them to  
> InstalledPackageInfo. However, then we have a strange situation  
> where some fields get distinguished status in InstalledPackageInfo.   
> Of course, for some of those fields we have richer types (e.g.  
> License), so it makes sense.
>
> So for me, I can't see any serious objections to doing this, but I'd  
> also ask on the cabal-devel at haskell.org list (in particular we  
> should hear what Duncan Coutts thinks).

Before implementing anything like general key,value pairs, I would  
like to see the exact usage of these fields? So Dan wants to query  
these dynamically using an API. I'm much more interested in having CPP  
macros defined so I can compile code conditionally. For this purpose,  
the key,value pairs are not necessarily suitable since Dan might want  
to define a pair that does not create a valid -Dkey=value instruction  
for CPP.

Cheers,
Axel.