Proposed ghc-pkg and cabal feature - right list?

[Dan Knapp]

Thanks for your feedback.  I'm mailing cabal-devel before I proceed.
Hopefully the
next time I post here will be with an implementation. :)


On Mon, Mar 15, 2010 at 11:38 AM, Simon Marlow <marlowsd at gmail.com> wrote:
> On 13/03/2010 20: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 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.
>>
>> Once again, I'm not asking anyone to do this work for me - I'm eager
>> to get my hands dirty and do it myself.  I just want to find out what
>> the process would be to get it accepted, once it works.
>
> 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).
>
> Cheers,
>        Simon
>



-- 
Dan Knapp
"An infallible method of conciliating a tiger is to allow oneself to
be devoured." (Konrad Adenauer)