presentation of dependencies in the web interface
Dependencies between packages are obviously more complex now that we have configurations. The web interface now has an experimental presentation of these dependencies transformed into disjunctive normal form, with the atoms being simple version ranges. It lacks tests of os, arch and impl, which will need to be added later. Still, people using configurations without those tests might like to check what it does to their packages.
On Thu, 2007-10-25 at 11:40 +0100, Ross Paterson wrote:
Dependencies between packages are obviously more complex now that we have configurations.
The web interface now has an experimental presentation of these dependencies transformed into disjunctive normal form, with the atoms being simple version ranges. It lacks tests of os, arch and impl, which will need to be added later. Still, people using configurations without those tests might like to check what it does to their packages.
_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Thanks for the quick fix, I just noticed the problem yesterday. 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 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. Duncan is currently implementing his proposal to use the 'package(...)' predicate to enable specifying differnent dependencies depending on the version of some package. We will still need to show this DNF representation of the dependencies, but it shouldn't assume that all flags are variable. BTW, do you think your code should/could go into Cabal, so that possibly other tools may take advantage of this feature? / Thomas
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.
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?
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-instal...
On Thu, Oct 25, 2007 at 02:02:22PM +0200, Thomas Schilling wrote:
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.
OK, but I wasn't planning to show flag names, just the environment tests.
On Thu, 2007-10-25 at 11:40 +0100, Ross Paterson wrote:
Dependencies between packages are obviously more complex now that we have configurations.
The web interface now has an experimental presentation of these dependencies transformed into disjunctive normal form, with the atoms being simple version ranges. It lacks tests of os, arch and impl, which will need to be added later. Still, people using configurations without those tests might like to check what it does to their packages.
I should be more careful with 3 vs 3.0 :-) For tar-0.1.1.1 I used: if flag(bytestring-in-base) -- bytestring was in base-2.0 and 2.1.1 Build-depends: base >= 2.0 && < 2.2 else -- in base 1.0 and 3.0 bytestring is a separate package Build-depends: base < 2.0 || >= 3, bytestring >= 0.9 if flag(split-base) Build-depends: base >= 3.0, directory, old-time else Build-depends: base < 3.0 which gives the deps: base (<2.0), binary (>=0.2), bytestring (>=0.9), unix-compat (>=0.1.2) or base (>=2.0&&<2.2), binary (>=0.2), unix-compat (>=0.1.2) or base (>=3&&<3.0), binary (>=0.2), bytestring (>=0.9), unix-compat (>=0.1.2) or base (>=3.0), binary (>=0.2), bytestring (>=0.9), directory, old-time, unix-compat (>=0.1.2) ie it has an extra line for what happens if base >= 3 but < 3.0 and that's presumably because I used a mixture of 3 and 3.0 in my specification above. Duncan
participants (3)
-
Duncan Coutts -
Ross Paterson -
Thomas Schilling