presentation of dependencies in the web interface

Thomas Schilling nominolo at googlemail.com
Thu Oct 25 08:02:22 EDT 2007


On Thu, 2007-10-25 at 12:48 +0100, Ross Paterson wrote:
> On Thu, Oct 25, 2007 at 01:17:43PM +0200, Thomas Schilling wrote:
> > I presume the final interface should be to give the user a simple way to
> > query the dependenies by giving assignments for OS, arch,
> > implementation, etc. and then dynamically (yes, using JavaScript)
> > updating the dependency list.  It shouldn't be hard to generate the
> > necessary code from the Cabal file.  I think the current way is okay for
> > now, though.
> 
> The pages are CGI output, so those could be extra parameters.
> 
> > The main problem with using this representation is, that it assumes that
> > flags are only used to let Cabal decide dependencies based on present
> > dependencies.  This is exactly the part I would *not* want to use them
> > for -- they are meant to be used to enable/disable certain features
> > like, e.g., using GTK or WXWindows or building with debugging support.
> 
> I don't quite follow you, but it treats optional features (if's without
> else's) as not creating dependencies.

The point is, that flags like "old-base" or "bytestring-in-base" (as,
for example, in [1]) are used solely to dispatch on the version of the
base package.  It should not be necessary for the user to invent flag
names for such uses.

> 
> > Duncan is currently implementing his proposal to use the 'package(...)'
> > predicate to enable specifying different dependencies depending on the
> > version of some package.
> 
> Is that written up somewhere?

http://www.haskell.org/pipermail/cabal-devel/2007-October/001189.html

/ Thomas

[1] ..
http://hackage.haskell.org/packages/archive/cabal-install/0.4.0/cabal-install.cabal




More information about the cabal-devel mailing list