April 2008 - cabal-devel

[Hackage] #223: allow per-package configuration options in config file
by Hackage 22 Aug '08

22 Aug '08

#223: allow per-package configuration options in config file ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.4 Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ---------------------------------+------------------------------------------ Currently only a subset of the configure command line flags can be stored in cabal-install's config file. There is no particularly good reason for this. It should be reasonably straightforward to do it generically and allow all configure options to be kept in the config file. This may require some unification of the API for managing command line flags (the Simple.Command module) and the API for loading and saving from config flags (in ParseUtils). Once this is done, it should be straightforward to keep per-package config options as well as global options in the cabal-install config file. These could be used to augment the options used when configuring a package. The order of overriding in cabal-install is currently: {{{ savedConfig `mappend` configFlags }}} That is, the configure options from the config file are overridden by the ones supplied on the command line. With per-package saved config we would extend this to: {{{ globalSavedConfig `mappend` packageSavedConfig pkg `mappend` configFlags }}} ie per-package saved, overrides global saved, but command line still overrides everything. The slightly tricky bit is in how the api for config files and command line flags should be made to work better with each other, so that one set of information can be read/written from either source. The rest should be straightforward. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/223> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 8

[Hackage] #184: cabal-install should report build results to hackage server
by Hackage 15 Aug '08

15 Aug '08

#184: cabal-install should report build results to hackage server ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install | Version: 1.2.2.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.4.2 Platform: Linux | ----------------------------+----------------------------------------------- One way to get a lot more testing data on hackage packages is if cabal- install could report back to the hackage server about build successes and failures. This information should be kept by hackage and used to distill information about which platforms configurations a package builds successfully and which it does not. This should provide useful information to developers to enable them to discover problems more quickly and useful information to users. An important consideration is privacy. Users should always have the option to not report anything and any information they report that is kept should not contain identifying information. This is particularly important when it comes to build logs which may contain paths etc. It should be clear to users what information they are reporting to the can decide for themselves if it meets their privacy needs. Since cabal can be used to build private code it is vital that it reports only on packages that were obtained from the hackage server. It is also vital that the information is sent to the correct hackage server. It's possible to set up private hackage server instances and it'd may be useful to collect build information "in house" too. So what information would be helpful? * build success or failure (qualified by what failed, build, docs, tests) * package name and version * hash of .cabal file just to make sure it's the same one we're all talking about and to detect local modifications. * precise versions of dependent packages that the package was built with. * os and arch strings * compiler flavour and version * versions of important build tools * In the case of a build failure, some part of the build log would be helpful. This is the most problematic part from a privacy point of view. This is quite a bit of raw data and we can expect to have many hundreds of such reports for popular packages. How can we distill useful information from this kind of data? I expect we would want to do some statistical analysis where we look for common traits in the results. The data forms a multi-dimensional space of boolean values. By looking down the rows/columns of this space we should be able to identify trends. For example if it always fails with ghc-6.8.x, or always fails on Windows. Excluding those obvious failures we then may be able to say that it does work on mac osx (except ghc-6.8.1) or that it does work with regex-posix-0.92 (except on windows), etc. This should allow us to give a summary saying yes/no to various properties of the environment. For failure cases developers should be able to get access to the more detailed data including build logs. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/184> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #229: Build C sources using the system's C compiler directly
by Hackage 15 Aug '08

15 Aug '08

#229: Build C sources using the system's C compiler directly ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- Currently Cabal builds C sources by going via ghc. On some platforms this introduces some limitations (Windows especially, I think). See this conversation for an example where it would be useful: http://www .mail-archive.com/haskell-cafe(a)haskell.org/msg37179.html -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/229> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #225: allow installing just specific bits, like just docs
by Hackage 15 Aug '08

15 Aug '08

#225: allow installing just specific bits, like just docs ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- Sometimes people would like to build and install just part of a cabal project, e.g. the documentation or one of the libraries or binaries. Specific use-cases are packaging for OS distro's and generating Haddock docs for code that was installed without it (cf the current state of Debian-stable). Igloo proposes the following user interface: ----- As long as docs, license and binaries can be (de)selected individually I don't really mind. If you want a concrete suggestion, we could have `--foo` and `--no-foo` for each thing, with the default being `--all` and the command line being processed left-to-right, e.g. {{{ cabal install --no-haddock-interfaces --docs --no-html }}} would install * all (which wouldn't actually contain anything) * docs (which wouldn't actually contain anything) * haddock-interfaces * license * everything under binaries ----- I broadly agree, but am slightly concerned there are dependencies amongst the various things that his syntax does not respect (e.g. one may need to install the libraries - e.g. one depending on a foreign library - in order to get a binary working). So either we have to vet the command lines or coarsen the flags. I hope Duncan and Igloo can draw on their packaging experience and determine what is actually useful. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/225> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #212: Overhaul Cabal's testsuite
by Hackage 15 Aug '08

15 Aug '08

#212: Overhaul Cabal's testsuite ----------------------------------+----------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: very hard (<1 week) | Ghcversion: 6.8.2 Platform: | ----------------------------------+----------------------------------------- The current testsuite based on HUnit is almost completely bitrotted. Anyone who wants to take this on has essentially a completely clean slate to work from. The current system is split into two parts. There are hunit tests in many of the modules guarded by #ifdef DEBUG. Then there are external tests in the `tests/` subdirectory. The #ifdef DEBUG style is annoying since it involves using more CPP than seem really necessary. A couple notes from the old `TODO` file: {{{ ** add a make target or command for tests we know will fail? ** setup test suite to run on --push? ** redirect non-hunit outputs to a file? }}} One possibility that is available to us now that was not before is using the hackage collection as part of a regression test. For example it should always be possible to parse all the `.cabal` files in the index. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/212> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #198: cabal install foo should upgrade foo if there's a newer version
by Hackage 12 Aug '08

12 Aug '08

#198: cabal install foo should upgrade foo if there's a newer version ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: Linux | ---------------------------------+------------------------------------------ if I have foo-1.0 installed, and foo-2.0 is available, "cabal install foo" should upgrade foo to version 2.0 -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/198> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 8

[Hackage] #175: cabal-install needs a new package dependency resolution algorithm
by Hackage 12 Aug '08

12 Aug '08

#175: cabal-install needs a new package dependency resolution algorithm ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: cabal-install | Version: 1.2.2.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.4.2 Platform: Linux | ----------------------------+----------------------------------------------- The current package dependency algorithm is pretty simple. It's main failing is that it cannot backtrack if it finds the solution is impossible. What we would like is a new dependency resolution algorithm that can backtrack. We would also like to be able to configure policy issues separately, perhaps as a parameter. It may also be handy to let users or the system add extra version constraints. The input is the set of available packages and the output is a list of packages to install, and the assignment of configuration flags to use for each one. As for the policy input, this might take the form of a function that picks between possible dependencies in a slot, this could then allow us to make choices like preferring installed packages over the latest available package version, or vica versa. See also symptoms of the existing system: * bug #168 -- lack of configurable policy * bug #174 -- lack of backtracking -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/175> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #267: cabal upload has poor error messages (just an HTTP response code)
by Hackage 12 Aug '08

12 Aug '08

#267: cabal upload has poor error messages (just an HTTP response code) ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- All these bugs are against the homeomorphic library I have written. To play along, you can do darcs get --partial http://www.cs.york.ac.uk/fp/darcs/homeomorphic $ cabal upload dist E:\Neil\homeomorphic>cabal upload dist\homeomorphic-0.1.tar.gz Hackage username: NeilMitchell Hackage password: yoda Uploading dist\homeomorphic-0.1.tar.gz... ERROR: dist\homeomorphic-0.1.tar.gz: 400 Error in upload 400 error in upload - not the worlds most helpful error message... Duncan says: Indeed. There is an error message available but I'm not sure how we get at it. Any ideas Ross? Another ticket for this one. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/267> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[Hackage] #213: allow wildcards in data-files or extra-source-files?
by Hackage 29 Jul '08

29 Jul '08

#213: allow wildcards in data-files or extra-source-files? ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- Some packages end up with very very long fields for data-files or extra- source-files. Is this a problem? Should we allow some kind of globing to make it a bit less verbose? {{{ extra-source-files: cbits/*.h c-sources: cbits/*.c }}} On the other hand, there is a danger with globing that you pick up too many files. Perhaps we can counter that by making the globing rather restrictive, like no subdirectory recursion, and only allowing *'s in the final directory component, so no {{{data/*/*}}} patterns. Is there a sweet spot that allows conciseness without including too much accidentally? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/213> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #232: implement extended syntax for package version ranges
by Hackage 29 Jul '08

29 Jul '08

#232: implement extended syntax for package version ranges ----------------------------+----------------------------------------------- Reporter: duncan | Owner: nominolo Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- Revised proposal: http://www.haskell.org/pipermail/cabal- devel/2008-January/001786.html Reproduced here: In order to make it easy for package package authors to describe correct and robust dependencies we (Duncan Coutts and I) propose the following syntactical extension to version range specifications in package files. == Wildcards == {{{ ~ 1.2.* ~~> >= 1.2 && < 1.3 }}} in general {{{ ~ x.y.* ~~> >= x.y && < x.(y+1) }}} The "~" operator should be read as "in the range of". Another option would have been "-", but this is used to specify exact versions in other parts of the Cabal infrastructure , e.g., "cabal install xmonad-0.5". This is the most common specification of package dependencies. The assumption is that changes in the last version number indicate only backwards compatible changes, as is suggested in the new package versioning policy [1]. The use of "*" matches the common usage as a wildcard character. == Upward Ranges == {{{ ~ 1.2.1+ ~~> >= 1.2.1 && < 1.3 }}} in general {{{ ~ x.y.z+ ~~> >= x.y.z && < x.(y+1) }}} The idea here is that sometimes packages need a certain patch level or, as in Cabal's case, a stable release and possible further bugfixes. In those cases the wildcard notation is too liberal, however the explicit range description would be too noisy (and possibly error prone). (Also, using "+" instead of "*" serves as better visual distinction.) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/232> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5