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. ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: presentation of dependencies in the web interface
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 ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #87: robustify release cabal-get
#87: robustify release cabal-get +--- Reporter: paolo |Owner: paolo Type: task | Status: new Priority: normal |Milestone: Component: cabal-install | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux +--- Comment (by nominolo): This seems to be obsolete. Can someone check please? -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/87#comment:11 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: presentation of dependencies in the web interface
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? ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #129: fetch fails without giving user feedback if the requested package does not exist
#129: fetch fails without giving user feedback if the requested package does not
exist
+---
Reporter: mnislaih |Owner: mnislaih
Type: defect | Status: closed
Priority: normal |Milestone:
Component: cabal-install | Version: HEAD
Severity: normal | Resolution: fixed
Keywords: | Difficulty: very easy (1 hour)
Ghcversion: 6.6| Platform: Mac OS
+---
Changes (by nominolo):
* status: assigned = closed
* resolution: = fixed
Comment:
The error message for {{{fetch}}} and {{{install}}} are the same now, in
cabal-install 0.4.
--
Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/129#comment:2
Hackage http://haskell.org/cabal/
Hackage: Cabal and related projects___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #29: perform package dependency analysis for cabal-install
#29: perform package dependency analysis for cabal-install +--- Reporter: ijones |Owner: ijones Type: enhancement| Status: closed Priority: normal |Milestone: Cabal-1.4 Component: cabal-install | Version: HEAD Severity: normal | Resolution: fixed Keywords: | Difficulty: hard Ghcversion: 6.2.1 | Platform: Linux +--- Changes (by nominolo): * status: new = closed * platform: = Linux * ghcversion: = 6.2.1 * resolution: = fixed Comment: Obsolete. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/29#comment:2 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #54: if a package is already newest version, avoid downloading and installing it
#54: if a package is already newest version, avoid downloading and installing it +--- Reporter: ijones |Owner: ijones Type: defect | Status: closed Priority: normal |Milestone: Cabal-1.4 Component: cabal-install | Version: Severity: normal | Resolution: fixed Keywords: | Difficulty: normal Ghcversion: 6.2.1 | Platform: Linux +--- Changes (by nominolo): * status: new = closed * resolution: = fixed Comment: Works in cabal-install 0.4 -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/54#comment:2 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: presentation of dependencies in the web interface
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 ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #87: robustify release cabal-get
#87: robustify release cabal-get +--- Reporter: paolo |Owner: paolo Type: task | Status: closed Priority: normal |Milestone: Component: cabal-install | Version: Severity: normal | Resolution: fixed Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux +--- Changes (by duncan): * status: new = closed * resolution: = fixed Comment: Yes, this is pretty old. We've deployed hackageDB and made releases of cabal-upload and cabal-install. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/87#comment:12 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: presentation of dependencies in the web interface
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.02.2), binary (=0.2), unix-compat (=0.1.2) or base (=33.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 ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
