Proposed ghc-pkg and cabal feature - right list?
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. Thanks in advance, -- Dan Knapp "An infallible method of conciliating a tiger is to allow oneself to be devoured." (Konrad Adenauer)
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@haskell.org list (in particular we should hear what Duncan Coutts thinks). Cheers, Simon
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
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@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)
participants (2)
-
Dan Knapp -
Simon Marlow