April 2012 - cabal-devel

[Hackage] #780: Simpler support for isolated/sandboxed builds
by Hackage 25 Apr '12

25 Apr '12

#780: Simpler support for isolated/sandboxed builds ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Cabal/cabal-install allows setting the install prefix and the package database. Together these allow creating isolated builds. This is clearly not sufficiently easy to use as there are now two projects that provide wrappers over cabal-install to provide more direct support for this use case: * http://github.com/creswick/cabal-dev/blob/master/README.md * http://www.haskell.org/haskellwiki/Capri The task is to investigate what user behaviour is desired and to integrate this in the best way with Cabal/cabal-install. This is probably related to: * ticket #556 about local config files (e.g. persistently setting some sandbox flag) * ticket #734 about supporting multiple local .cabal files * ticket #524 about supporting file, directory and url targets for packages and .cabal files -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/780> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[Hackage] #945: Fails to find install plan for containers package tests
by Hackage 25 Apr '12

25 Apr '12

#945: Fails to find install plan for containers package tests ---------------------------------+------------------------------------------ Reporter: tibbe | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.14.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: 7.4.1 Platform: Linux | ---------------------------------+------------------------------------------ The containers package has a test-suite section which seems to create a cycle when building the package. Could it be that Cabal treats the package as one unit instead of treating the library and test-suite sections separately, which should remove the cycle. {{{ $ cabal install --enable-tests -v3 searching for ghc in path. found ghc at /usr/local/bin/ghc ("/usr/local/bin/ghc",["--numeric-version"]) /usr/local/bin/ghc is version 7.4.1 looking for tool "ghc-pkg" near compiler in /usr/local/bin found ghc-pkg in /usr/local/bin/ghc-pkg ("/usr/local/bin/ghc-pkg",["--version"]) /usr/local/bin/ghc-pkg is version 7.4.1 ("/usr/local/bin/ghc",["--supported-languages"]) ("/usr/local/bin/ghc",["--info"]) Reading installed packages... ("/usr/local/bin/ghc-pkg",["dump","--global","-v0"]) ("/usr/local/bin/ghc-pkg",["dump","--user","-v0"]) ("/usr/local/bin/ghc",["--print-libdir"]) Reading available packages... Choosing modular solver. Resolving dependencies... [__0] trying: containers-0.5.0.0 (user goal) [__1] next goal: base (dependency of containers-0.5.0.0) [__1] rejecting: base-3.0.3.2, 3.0.3.1 (global constraint requires installed instance) [__1] trying: base-4.5.0.0/installed-f76... [__2] trying: rts-1.0/installedbuil... (dependency of base-4.5.0.0/installed-f76...) [__3] trying: integer-gmp-0.4.0.0/installed-ec8... (dependency of base-4.5.0.0/installed-f76...) [__4] rejecting: containers-0.5.0.0:!test (global constraint requires opposite flag selection) [__4] trying: containers-0.5.0.0:*test [__5] trying: test-framework-quickcheck2-0.2.12.1 (dependency of containers-0.5.0.0:*test) [__6] trying: test-framework-quickcheck2-0.2.12.1:+base4 [__7] trying: test-framework-quickcheck2-0.2.12.1:-base3 [__8] trying: random-1.0.1.1/installed-3be... (dependency of test- framework-quickcheck2-0.2.12.1:+base4) [__9] trying: time-1.4/installed-3e1... (dependency of random-1.0.1.1 /installed-3be...) [_10] trying: old-locale-1.0.0.4/installed-29b... (dependency of time-1.4 /installed-3e1...) [_11] trying: extensible-exceptions-0.1.1.4/installed-d27... (dependency of test-framework-quickcheck2-0.2.12.1) [_12] trying: test-framework-hunit-0.2.7 (dependency of containers-0.5.0.0:*test) [_13] trying: test-framework-hunit-0.2.7:+base4 [_14] trying: test-framework-hunit-0.2.7:-base3 [_15] trying: test-framework-0.6 (dependency of containers-0.5.0.0:*test) [_16] trying: test-framework-0.6:-tests [_17] trying: test-framework-0.6:+splitbase [_18] trying: hostname-1.0 (dependency of test-framework-0.6) [_19] trying: xml-1.3.12 (dependency of test-framework-0.6) [_20] trying: text-0.11.2.0/installed-a62... (dependency of xml-1.3.12) [_21] trying: bytestring-0.9.2.1/installed-4ad... (dependency of xml-1.3.12) [_22] trying: regex-posix-0.95.1 (dependency of test-framework-0.6) [_23] trying: regex-posix-0.95.1:+splitbase [_24] trying: regex-posix-0.95.1:+newbase [_25] trying: regex-base-0.93.2 (dependency of regex- posix-0.95.1:+newbase) [_26] trying: regex-base-0.93.2:+splitbase [_27] trying: regex-base-0.93.2:+newbase [_28] trying: mtl-2.1/installed-0a8... (dependency of regex- base-0.93.2:+newbase) [_29] trying: transformers-0.3.0.0/installed-f23... (dependency of mtl-2.1 /installed-0a8...) [_30] trying: ansi-wl-pprint-0.6.4 (dependency of test-framework-0.6) [_31] trying: ansi-wl-pprint-0.6.4:+newbase [_32] trying: ansi-wl-pprint-0.6.4:-example [_33] trying: ansi-terminal-0.5.5 (dependency of test-framework-0.6) [_34] trying: ansi-terminal-0.5.5:+splitbase [_35] trying: ansi-terminal-0.5.5:-example [_36] trying: unix-2.5.1.0/installed-346... (dependency of ansi- terminal-0.5.5) [_37] trying: QuickCheck-2.4.2 (dependency of containers-0.5.0.0:*test) [_38] trying: QuickCheck-2.4.2:+templatehaskell [_39] trying: QuickCheck-2.4.2:+base4 [_40] trying: QuickCheck-2.4.2:+base3 [_41] next goal: template-haskell (dependency of QuickCheck-2.4.2:+templatehaskell) [_41] rejecting: template-haskell-2.7.0.0/installed-164... (conflict: containers==0.5.0.0, template-haskell => containers==0.4.2.1/installed- 7c5...) [_41] trying: template-haskell-2.7.0.0 [_42] trying: pretty-1.1.1.0/installed-7e1... (dependency of template- haskell-2.7.0.0) [_43] trying: HUnit-1.2.4.2 (dependency of containers-0.5.0.0:*test) [_44] trying: HUnit-1.2.4.2:+base4 [_45] trying: ghc-prim-0.2.0.0/installed-bd2... (dependency of containers-0.5.0.0) [_46] trying: deepseq-1.3.0.0/installed-6c1... (dependency of containers-0.5.0.0) [_47] next goal: array (dependency of containers-0.5.0.0) [_47] trying: array-0.4.0.0/installed-0b3... [_48] done cabal: internal error: could not construct a valid install plan. The proposed (invalid) plan contained the following problems: The following packages are involved in a dependency cycle test-framework- hunit-0.2.7, test-framework-0.6, regex-posix-0.95.1, regex-base-0.93.2, containers-0.5.0.0, test-framework-quickcheck2-0.2.12.1, QuickCheck-2.4.2, template-haskell-2.7.0.0 }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/945> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #940: cabal build silently ignores test-suites without Build-Depends
by Hackage 25 Apr '12

25 Apr '12

#940: cabal build silently ignores test-suites without Build-Depends ----------------------------+----------------------------------------------- Reporter: edsko | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.10.2.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: 7.4.1 Platform: Mac OS | ----------------------------+----------------------------------------------- A section such as Test-Suite foo Type: exitcode-stdio-1.0 Main-Is: test-foo.hs without a Build-Depends will not be built by "cabal build", and a subsequent "cabal test" will then complain "cabal: No test suites enabled. Did you remember to configure with '--enable-tests'?" -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/940> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #938: cabal test does not tail standard output of the running test executable
by Hackage 25 Apr '12

25 Apr '12

#938: cabal test does not tail standard output of the running test executable ---------------------------------+------------------------------------------ Reporter: fushunpoon | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.10.2.0 Severity: minor | Keywords: Difficulty: easy (<4 hours) | Ghcversion: Platform: | ---------------------------------+------------------------------------------ == Problem: == cabal test does not tail standard output of the running test executable. Instead, any output from the executable is output right at the end of the test process in one batch. == Motivation: == It is incredibly useful to have cabal test tail the stdout of the test executable currently being executed such that CI tools such as TeamCity can be made to record the time it takes to run individual tests. == Reproduction: == Run the following simple executable as a test executable with {{{cabal test --show-details=always}}} {{{ module Main where import Control.Concurrent delay = 5000000 main = do putStrLn "First message" threadDelay delay putStrLn "Second message" threadDelay delay putStrLn "Third message" threadDelay delay }}} Instead of outputting each line ("First/Second/Third message") five seconds after another, all three lines are output along with test result reporting all at once at the end of the test suite. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/938> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

Re: [Hackage] #592: cabal test does not detect that cabal build needs to be re-run
by Hackage 24 Apr '12

24 Apr '12

#592: cabal test does not detect that cabal build needs to be re-run ----------------------------+----------------------------------------------- Reporter: kowey | Owner: ttuegel Type: defect | Status: assigned Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Comment(by tibbe): Replying to [comment:11 ttuegel]: > OK, it's easy enough to configure and build before 'cabal test' or 'cabal benchmark'. Obviously, these commands have been updated to take the 'cabal configure' options, as well. I thought about installing dependencies, too, but decided against it: I don't think people expect 'cabal test' to install packages on their system, so it's probably not a good idea. Just checking, but is this the behavior you would expect, i.e., configure and build, but don't install missing dependencies? I think it's a good compromise for now. I'd prefer if (and have argued for) `cabal build/test/bench` to "do what I mean." Until we all agree that they should install dependencies etc I think having `cabal test` imply `cabal configure` and `cabal build` is a good compromise for now. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/592#comment:12> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #592: cabal test does not detect that cabal build needs to be re-run
by Hackage 24 Apr '12

24 Apr '12

#592: cabal test does not detect that cabal build needs to be re-run ----------------------------+----------------------------------------------- Reporter: kowey | Owner: ttuegel Type: defect | Status: assigned Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Comment(by ttuegel): Replying to [comment:9 tibbe]: > Replying to [comment:8 ttuegel]: > > Even with the patch I just attached, 'cabal configure' needs to be run first, but I doubt we want to change that behavior. > > I think we do! We already run configure automatically before build in most cases. I think we should always do that. OK, it's easy enough to configure and build before 'cabal test' or 'cabal benchmark'. Obviously, these commands have been updated to take the 'cabal configure' options, as well. I thought about installing dependencies, too, but decided against it: I don't think people expect 'cabal test' to install packages on their system, so it's probably not a good idea. Just checking, but is this the behavior you would expect, i.e., configure and build, but don't install missing dependencies? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/592#comment:11> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #447: build multiple packages in parallel
by Hackage 24 Apr '12

24 Apr '12

#447: build multiple packages in parallel ---------------------------------+------------------------------------------ Reporter: duncan | Owner: refold Type: enhancement | Status: assigned Priority: high | Milestone: cabal-install-0.16 Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ---------------------------------+------------------------------------------ Comment(by refold): Parallel patches were [https://github.com/23Skidoo/cabal moved to GitHub]: {{{ git clone git://github.com/23Skidoo/cabal.git cabal-parallel-install cd cabal-parallel-install git checkout parallel-install }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/447#comment:9> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #810: cabal-install requests credentials even when they are listed in the config
by Hackage 24 Apr '12

24 Apr '12

#810: cabal-install requests credentials even when they are listed in the config ---------------------------------+------------------------------------------ Reporter: basvandijk | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.10.1.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ I have listed my Hackage username and password in my cabal config: `/home/bas/.cabal/config`: {{{ username: BasVanDijk password: ********** }}} Previously this enabled me to `cabal upload` packages to Hackage without entering my credentials. However the new `cabal-install` requests my credentials. {{{ $ cabal --version cabal-install version 0.10.2 using version 1.10.1.0 of the Cabal library }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/810> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #941: add 'hyperlink-source: true/false' to ~/.cabal/config
by Hackage 24 Apr '12

24 Apr '12

#941: add 'hyperlink-source: true/false' to ~/.cabal/config ---------------------------------+------------------------------------------ Reporter: bfr | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.14.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Having to remember to add the --hyperlink-source flag to cabal install is a major pain. See also #534, where others have requested the same feature. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/941> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

Re: [Haskell-cafe] Announce: Hackager - new version of hackage-test
by Duncan Coutts 23 Apr '12

23 Apr '12

Good work David. I used to do something like this for Cabal regression testing but the method I used didn't scale well as hackage grew. I'll look into using your tool next time for testing a major Cabal / cabal-install release. Duncan On 23 April 2012 21:37, David Terei <dave.terei(a)gmail.com> wrote: > Hi all, > > I've updated the old hackage-test tool and renamed to hackager. > > http://hackage.haskell.org/package/hackager > > Hackager is a tool to automate the compiling of all packages on > Hackage. It builds each package on hackage in isolation and records > the results. The purpose being to catch regressions caused by changes > to GHC (and Cabal although this was not the motivation). Two runs of > Hackager can be compared, so the first run is done with a known > version of GHC and the next run with a new, experimental version of > GHC... ect. > > The improvements to Hackager over hackage-test are: > * Parallelized the build process. Can now specify how many packages to > build in parallel, which cuts total run time down greatly (e.g 2 days > -> 5 hours) > * hackage-test and hackage-report are now one tool, 'hackager' that > works as a mutli-command tool. > * Proper option handling > * Fixed some stability issues > > The new homepage for development can be found here: > https://github.com/dterei/Hackager > > Cheers, > David > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0