March 2012 - cabal-devel

darcs patch: Add a new checkout Command (and 1 more)
by Joachim Breitner 20 Jul '13

20 Jul '13

Hi, the small feature implemented by the attached patches could make it more convenient for people to quickly and easily contribute to hackage packages. Do you want me to open a ticket for this or can you appl yit right away? Thanks, Joachim 2 patches for repository http://darcs.haskell.org/cabal-install: Sun Nov 7 12:35:32 CET 2010 Joachim Breitner <mail(a)joachim-breitner.de> * Add a new checkout Command Given a package name, this uses the SourceRepo field of the newest versionf of that pacakge to figure out the repository location and calls the right VCS invocation. Sun Nov 7 12:43:35 CET 2010 Joachim Breitner <mail(a)joachim-breitner.de> * Add a --dry-run flag to cabal checkout

2 3

hackage-server: index format
by Antoine Latter 20 Dec '12

20 Dec '12

Hi folks, The index tar-ball on Hackage has an odd naming convention. Package descriptions are given paths of the form: ./$pkg/$version/$pkg.cabal including the leading "./". I'm guessing that this is done as a method of distinguishing non-package meta-data. Is this a convention we need to preserve? Thanks, Antoine

6 12

[Hackage] #935: implementation of Distribution.Version.invertVersionRange
by Hackage 26 Oct '12

26 Oct '12

#935: implementation of Distribution.Version.invertVersionRange ----------------------------------+----------------------------------------- Reporter: dsf | Owner: Type: enhancement | Status: new Priority: low | Milestone: Component: Cabal library | Version: 1.10.2.0 Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: 7.4.1 Platform: | ----------------------------------+----------------------------------------- Attached is an implementation of a function to return the complement of a VersionRange. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/935> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #777: cabal install {hledger, others} ExitFailure 11
by Hackage 14 Aug '12

14 Aug '12

#777: cabal install {hledger, others} ExitFailure 11 ---------------------------------+------------------------------------------ Reporter: philips | Owner: Type: defect | Status: new Priority: normal | Milestone: cabal-install-0.8 Component: cabal-install tool | Version: 1.8.0.2 Severity: normal | Keywords: ExitFailure Difficulty: unknown | Ghcversion: Platform: Linux | ---------------------------------+------------------------------------------ I am getting ExitFailure 11 when trying to install hledger on Debian and openSUSE. I reported this to the hledger author, Simon, and he said he is experiencing this on his machines too and for other packages, not just hledger. Log file attached. Summary below: {{{ ledger:~/ $ cabal install -v3 hledger Lots of debug output (see attached)... hledger-0.13 failed during the configure step. The exception was: ExitFailure 11 ledger:~/ $ cabal --version cabal-install version 0.8.2 using version 1.8.0.2 of the Cabal library ledger:~/ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.12.1 }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/777> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 11

[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] #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

Cabal's detailed test interface
by Thomas Tuegel 22 Apr '12

22 Apr '12

Greetings interested Cabal users and developers! I am pleased to present another revision of Cabal's detailed test interface for your scrutiny. I have attached a patch for the Cabal repository to this message so you can try the new interface and test runner for yourselves, but the interface from Distribution.TestSuite is included below with a few of my comments. This interface is based very heavily on Duncan's proposal from our last round of discussion. I indicated deviations by comments in the source, but the commit log is a good summary of the changes: * The constructors of 'Tests' have been renamed. I think 'TestGroup' and 'ExtraTestOptions' are redundant: it is clear from context what sort of Group and what sort of ExtraOptions are being considered and qualified imports can resolve any name conflicts. Group and ExtraOptions have the advantage of improving the brevity of pattern matches on Tests, which are used very often in D.S.Test. * The 'concurrentSafe :: Bool' field of TestInstance has become the 'concurrently' field of Group, allowing package and test framework authors greater control over concurrency. * The 'Finished' constructor of 'Progress' now contains the options used to run the test in addition to the test result. Without returning the options, it would be difficult to extract the RNG seed used to run a test. * A detailed test suite module now exports the symbol 'test :: IO Tests'. This enables the use of IO to enumerate the tests in a group, suggested by Duncan as a way to accommodate the GHC test suite. > module Distribution.TestSuite > ( TestInstance(..) > , OptionDescr(..) > , OptionType(..) > , Tests(..) > , Options > , Progress(..) > , Result(..) > ) where > > data TestInstance = TestInstance > { run :: IO Progress -- ^ Perform the test. > , name :: String -- ^ A name for the test, unique within a > -- test suite. > , tags :: [String] -- ^ Users can select groups of tests by > -- their tags. > , options :: [OptionDescr] -- ^ Descriptions of the options recognized > -- by this test. > , setOption :: String -> String -> Either String TestInstance > -- ^ Try to set the named option to the given value. Returns an error > -- message if the option is not supported or the value could not be > -- correctly parsed; otherwise, a 'TestInstance' with the option set to > -- the given value is returned. > } > > data OptionDescr = OptionDescr > { optionName :: String > , optionDescription :: String -- ^ A human-readable description of the > -- option to guide the user setting it. > , optionType :: OptionType > , optionDefault :: Maybe String > } > deriving (Eq, Read, Show) > > data OptionType > = OptionFile > { optionFileMustExist :: Bool > , optionFileIsDir :: Bool > , optionFileExtensions :: [String] > } > | OptionString > { optionStringMultiline :: Bool > , optionStringDescription :: String > } > | OptionNumber > { optionNumberIsInt :: Bool > , optionNumberBounds :: (Maybe String, Maybe String) > } > | OptionBool > | OptionEnum [String] > | OptionSet [String] > | OptionRngSeed > deriving (Eq, Read, Show) > > data Tests > = Test TestInstance > | Group > { groupName :: String > , concurrently :: Bool -- ^ If true, then the child 'Test's or > -- 'Group's can safely be run concurrently; > -- otherwise, they must be run in series. > , groupTests :: [Tests] > } > | ExtraOptions [OptionDescr] Tests > > type Options = [(String, String)] > > data Progress = Finished Options Result > -- ^ The options used must be returned when the test is finished, > -- or it will not be possible to recreate tests taking a random > -- seed. > | Progress String (IO Progress) > > data Result = Pass > | Fail String > | Error String > deriving (Eq, Read, Show) As always, your comments are appreciated. Thanks! -- Thomas Tuegel

4 15

[Hackage] #921: cabal build should imply cabal configure
by Hackage 20 Apr '12

20 Apr '12

#921: cabal build should imply cabal configure ---------------------------------+------------------------------------------ Reporter: tibbe | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ `cabal build` should run `cabal configure` if needed, even if the user never ran `cabal configure` manually before. Right now `cabal build` without `cabal configure` gives: {{{ cabal: Run the 'configure' command first. }}} We should simply run `cabal configure` automatically, with no flags set. If the user wants different flags he/she can run `cabal configure` manually. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/921> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #661: optionally select the oldest available dependencies rather than the newest
by Hackage 20 Apr '12

20 Apr '12

#661: optionally select the oldest available dependencies rather than the newest ----------------------------+----------------------------------------------- Reporter: benmachine | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- When developing a package, you want to specify as wide a range of build- depends as possible, but it's often quite tedious to keep checking if your latest development effort hasn't made your package incompatible with some ancient version of a library you use. In view of this I think it would be helpful to have an option that asks cabal configure to pick the oldest possible version of each dependency, so you could quickly and easily ensure that at least the two endpoints are covered. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/661> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #906: cabal install cabal-install-0.10.2 fails due to dependencies
by Hackage 16 Apr '12

16 Apr '12

#906: cabal install cabal-install-0.10.2 fails due to dependencies ---------------------------------+------------------------------------------ Reporter: AndreasVoellmy | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ cabal install cabal-install-0.10.2 fails for me. The problem is that it depends on unix < 2.5 and versions of unix before 2.5 depend on base < 4.4. But base 4.4 is selected very early on in the cabal install. Later versions of unix (i.e. 2.5.0.0) work with base < 4.5, so it seems like this issue could be fixed by releasing a new version of cabal-install that works with unix 2.5. Here is the output from cabal install cabal-install-0.10.2 -v3 --dry-run: {{{ 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.2.1 looking for package tool: ghc-pkg near compiler in /usr/local/bin found package tool in /usr/local/bin/ghc-pkg ("/usr/local/bin/ghc-pkg",["--version"]) /usr/local/bin/ghc-pkg is version 7.2.1 ("/usr/local/bin/ghc",["--supported-languages"]) Reading installed packages... ("/usr/local/bin/ghc-pkg",["dump","--global","-v2"]) ("/usr/local/bin/ghc-pkg",["dump","--user","-v2"]) ("/usr/local/bin/ghc",["--print-libdir"]) Reading available packages... Resolving dependencies... selecting cabal-install-0.10.2 (hackage) and discarding Cabal-1.1.6, 1.2.1, 1.2.2.0, 1.2.3.0, 1.2.4.0, 1.4.0.0, 1.4.0.1, 1.4.0.2, 1.6.0.1, 1.6.0.2, 1.6.0.3, 1.8.0.2, 1.8.0.4, 1.8.0.6, 1.10.0.0, 1.12.0, HTTP-3000.0.0, 3001.0.0, 3001.0.1, 3001.0.2, 3001.0.3, 3001.0.4, 3001.1.3, 3001.1.4, 3001.1.5, 4000.0.0, 4000.0.1, pretty-1.1.0.0, process-1.1.0.0, time-1.0, 1.3, unix-2.5.0.0, zlib-0.2 and 0.3 selecting base-4.4.0.0 (installed) selecting ffi-1.0 (installed) selecting ghc-prim-0.2.0.0 (installed) selecting integer-gmp-0.3.0.0 (installed) selecting rts-1.0 (installed) selecting random-1.0.1.0 (installed or hackage) and discarding random-1.0.0.0, 1.0.0.1, 1.0.0.2 and 1.0.0.3 selecting time-1.2.0.5 (installed or hackage) and discarding time-1.1.2.0, 1.1.2.1, 1.1.2.2, 1.1.2.3, 1.1.2.4, 1.1.3, 1.1.4, 1.2, 1.2.0.1, 1.2.0.2, 1.2.0.3 and 1.2.0.4 selecting zlib-0.5.3.1 (hackage) and discarding zlib-0.4, 0.4.0.1, 0.4.0.2, 0.4.0.3, 0.4.0.4, 0.5.0.0 and 0.5.2.0 selecting HTTP-4000.1.2 (hackage) and discarding HTTP-4000.0.2, 4000.0.3, 4000.0.4, 4000.0.5, 4000.0.6, 4000.0.7, 4000.0.8, 4000.0.9, 4000.0.10, 4000.1.0 and 4000.1.1 selecting network-2.3.0.5 (hackage) and discarding network-2.0, 2.1.0.0, 2.2.0.0, 2.2.0.1, 2.2.1, 2.2.1.1, 2.2.1.2, 2.2.1.3, 2.2.1.4, 2.2.1.5, 2.2.1.6, 2.2.1.7, 2.2.1.8, 2.2.1.9, 2.2.1.10, 2.2.3, 2.2.3.1, 2.3, 2.3.0.1, 2.3.0.2, 2.3.0.3 and 2.3.0.4 selecting parsec-3.1.1 (hackage) and discarding parsec-2.0, 2.1.0.0, 2.1.0.1, 3.0.0, 3.0.1 and 3.1.0 selecting bytestring-0.9.2.0 (installed or hackage) and discarding bytestring-0.9, 0.9.0.1, 0.9.0.2, 0.9.0.3, 0.9.0.4, 0.9.1.0, 0.9.1.1, 0.9.1.2, 0.9.1.3, 0.9.1.4, 0.9.1.5, 0.9.1.6, 0.9.1.7, 0.9.1.8, 0.9.1.9 and 0.9.1.10 selecting mtl-2.0.1.0 (installed or hackage) and discarding mtl-1.0, 1.1.0.0, 1.1.0.1, 1.1.0.2, 1.1.1.0, 1.1.1.1, 2.0.0.0, transformers-0.0.0.0, 0.0.1.0, 0.1.0.0, 0.1.0.1, 0.1.1.0, 0.1.3.0 and 0.1.4.0 selecting transformers-0.2.2.0 (installed or hackage) and discarding transformers-0.2.0.0 and 0.2.1.0 selecting Cabal-1.10.2.0 (hackage) and discarding Cabal-1.10.1.0 selecting process-1.0.1.5 (hackage) and discarding filepath-1.0, process-1.0.0.0, 1.0.1.1, 1.0.1.2, 1.0.1.3 and 1.0.1.4 selecting pretty-1.0.1.2 (hackage) and discarding pretty-1.0.0.0, 1.0.1.0 and 1.0.1.1 selecting directory-1.1.0.1 (installed or hackage) and discarding directory-1.0.0.0, 1.0.0.3, 1.0.1.0, 1.0.1.1, 1.0.1.2 and 1.1.0.0 selecting cabal: cannot configure unix-2.4.2.0. It requires base >=4.2 && <4.4 For the dependency on base >=4.2 && <4.4 there are these packages: base-4.2.0.0, base-4.2.0.1, base-4.2.0.2, base-4.3.0.0 and base-4.3.1.0. However none of them are available. base-4.2.0.0 was excluded because base-4.4.0.0 was selected instead base-4.2.0.0 was excluded because of the top level dependency base -any base-4.2.0.1 was excluded because base-4.4.0.0 was selected instead base-4.2.0.1 was excluded because of the top level dependency base -any base-4.2.0.2 was excluded because base-4.4.0.0 was selected instead base-4.2.0.2 was excluded because of the top level dependency base -any base-4.3.0.0 was excluded because base-4.4.0.0 was selected instead base-4.3.0.0 was excluded because of the top level dependency base -any base-4.3.1.0 was excluded because base-4.4.0.0 was selected instead base-4.3.1.0 was excluded because of the top level dependency base -any }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/906> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2