Re: Proposed ghc-pkg and cabal feature - right list?
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-de...@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.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Proposed ghc-pkg and cabal feature - right list?
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-de...@haskell.org list (in particular we should hear what Duncan Coutts thinks). Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Proposed ghc-pkg and cabal feature - right list?
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 marlo...@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-de...@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) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
