October 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

Gearing up for a cabal-install-1.16.0 release
by Johan Tibell 03 Dec '12

03 Dec '12

Hi all, There's been a long time since we had a cabal-install release and there are a lot of bug fixes in the repo we need to get out there. After discussing with Duncan we agreed that the cabal-install release should depend on the already released Cabal-1.16.0 package. I've created a new branch, cabal-install-1.16.0, for making the cabal-install-1.16.0 release. The branch was made from the point in the history where Cabal-1.16 was released. There were some patches on the cabal-1.16 branch that never made it into the Cabal-1.16 release. If there are any commits on the cabal-1.16 branch that you think should definitely be in cabal-install-1.16.0, please let me know and I will try to cherry-pick them. Here's the list of commits: https://github.com/haskell/cabal/compare/cabal-install-1.16.0...cabal-1.16 N.B. Commits that require unreleased changes to the Cabal library cannot be cherry-picked into this release, as we're not making a new release of Cabal the library. P.S. There will be more Cabal/cabal-install releases in the future so lets not try to cram unnecessary stuff in this release. The goal is to get almost a year's worth of unreleased stuff out there in a non-eventful manner. Cheers, Johan

10 15

Providing a smooth default user experience
by Johan Tibell 30 Nov '12

30 Nov '12

Hi all, Sensible defaults are important to provide a smooth user experience, especially for first-time users. There are a few areas where I think cabal could improve its default behavior. In particular, here are a couple of changes I would like to make: *cabal build should imply cabal install --only-dependencies * If you're currently working on a package, the right [1] way to build it is as follows: cabal install --only-dependencies cabal build (Note that in HEAD cabal build implies cabal configure so that step is no longer necessary, unless you need set some configure flags.) However, this is unintuitive and repetitive and many users end up using cabal install instead. The reasons I've heard for not having build imply installing dependencies is that users might not want packages to be downloaded from the internet, unless they explicitly use cabal install. While that's a fair point, I think it should be an opt-out rather than an opt-in because: - Users will end up have to install the dependencies anyway and there's typical no other options than installing them from Hackage. - Many users use cabal install instead of cabal build, for the reasons given above, making it a moot point. Proposal: add a --install-dependencies flag to cabal build that defaults to True. Once we start installing dependencies by default, the very first run of cabal build may take a long time, especially if sandboxing is used, so I think we should output the following message before installing dependencies: "Installing dependencies. This may take a long time if this is the first time you build this package." *Sandboxing should be used by default* This follows the "make it correct, then make it fast" principle. Sandboxing helps with a certain class of build problems, namely problems due to two different builds overwriting each others' dependencies in the shared package database. This problem shows up as a dangerously sounding cabal warning message, mentioning the --force-reinstalls flag. Sandboxing is an imperfect solution to this problem, requiring more rebuilding of packages than strictly necessary. A final solution would involve something like a Nix-style, append-only package database. The Nix solution is being worked on, as part of GSoC, but it's a difficult problem and it requires more wide-reaching changes (e.g. to ghc, ghc-pkg, ghci, and cabal). Since sandboxing is working today (with a few minor tweaks yet to be done) and it can be transparently replaced with a better solution once we have one, I think we should enable it by default in 1.18. Since sandboxing will result in more rebuilding, we should also enabled parallel builds by default, as they typically speed up builds by a factor of 2. Finally I think we need to improve messaging. We could use the same messaging as above i.e. "Installing dependencies. This may take a long time if this is the first time you build this package." Adding sandboxing by default also makes it easier to depend on unreleased versions of packages, as it has an add-source <dir> sub-command for managing those. *We should add a cabal run command* This proposal will only affect a small group of users, but will give those users a better user experience and hopefully encourage them to use cabal the right way. When developing e.g. web apps using Snap, the user needs to build and run an executable. You can do this today by running cabal build dist/build/my-exe/my-exe but e.g. the Snap documentation instead encourages users to do cabal install my-exe Perhaps because it's shorter and requires less explanation of where cabal puts its build output. I think we could improve this use case by introducing a new command, cabal run, with the following parameters: cabal run <executable> <args> which would run cabal build dist/build/<executable>/<executable> <args> Comments welcome! Cheers, Johan 1. The reason this is the right way is that you don't want to litter your shared package database with unreleased packages, as other packages might be built against these unreleased packages by misstake.

6 20

patch applied (hackage-server): "Move some mime-type validation utils to their own module" and 3 others
by devnull＠community.haskell.org 31 Oct '12

31 Oct '12

Wed Oct 31 15:29:40 GMT 2012 Duncan Coutts <duncan(a)well-typed.com> * Move some mime-type validation utils to their own module Ignore-this: 9da513216aed47143a7fe4f3c937bf5f M ./Distribution/Server/Features/Mirror.hs -21 M ./Distribution/Server/Framework.hs +2 A ./Distribution/Server/Framework/Validation.hs M ./hackage-server.cabal +1 Wed Oct 31 15:30:58 GMT 2012 Duncan Coutts <duncan(a)well-typed.com> * Allow users to have no auth info at all Ignore-this: fb9c17df293119c82894969e4ce17cf1 This lets us create users in one step, and set auth info in another M ./Distribution/Server/Framework/Auth.hs -1 +1 M ./Distribution/Server/Users/Types.hs +1 Wed Oct 31 15:38:22 GMT 2012 Duncan Coutts <duncan(a)well-typed.com> * Add user PUT/DELETE methods, and htpasswd PUT Ignore-this: 71568d309896c2ef2ea364fbe6a78cb0 Needed by the new import client, but useful generally for scripting. M ./Distribution/Server/Features/Users.hs -5 +56 Wed Oct 31 15:40:50 GMT 2012 Duncan Coutts <duncan(a)well-typed.com> * Add initial work on a new data import client Ignore-this: 8261fc1dd71301560086317d23c8ba8b For scripting, and for importing the data from the old hackage A ./ImportClient/ A ./ImportClient.hs A ./ImportClient/BulkImport.hs A ./ImportClient/HtPasswdDb.hs A ./ImportClient/UploadLog.hs M ./hackage-server.cabal +23

1 0

patch applied (hackage-server): "System.Directory.getModificationTime does not return ClockTime since version 1.2" and 1 others
by devnull＠community.haskell.org 31 Oct '12

31 Oct '12

Wed Oct 17 16:36:12 BST 2012 Jan Minarik <jan(a)minarik.net> * System.Directory.getModificationTime does not return ClockTime since version 1.2 Ignore-this: 6aee54ac149b7c9b8fd4ff6fab5134cf M ./hackage-server.cabal -1 +1 Thu Oct 18 15:31:50 BST 2012 Jan Minarik <jan(a)minarik.net> * cabal config file is not written during every build run Ignore-this: df993a71898765baf2dcb77197d0aafd Cabal-config was being overwritten each time the hackage-build build has been run. It was not possible to create a custom caba config, such as inserting multiple hackage servers. M ./BuildClient.hs -1 +3

1 0

Cabal needs more tests
by Johan Tibell 26 Oct '12

26 Oct '12

Hi all, Regressions in Cabal are getting more common. Cabal have a tougher correctness problem that your average Haskell program, as it * does a lot of I/O (e.g. calling out to other programs), * needs to do different things on different operating systems, and * includes rarely tested combinations of features (e.g. compiling a TH module with profiling and shared libraries). Manual testing is not an effective way to make sure that Cabal stays bug free, as it's hard to remember all possible combinations that ought to be tested and such manual testing isn't done after each commit, making breakages go unnoticed for a long time. I've been working on improving our test infrastructure by running a build bot at: http://ci.johantibell.com/job/cabal/ That build bot only tests on Linux. I'm working on setting up a Windows build bot, but progress has been slow. Here's what I'm asking of you as Cabal contributors: * Have a look at the current build bot failures. Do you know how to fix any of the failing tests? * When you write a new feature, try to include a test. Running tests is as simple as cd Cabal && cabal configure --enable-tests && cabal build && cabal test * If you have some spare time, write a test for one of the existing features (perhaps your own). There are two test suites in the source repo, the package-tests suites and the unit-tests suites. If possible, try to create unit tests instead of package tests, as they are much faster to run and give better error messages on failure. Cheers, Johan

1 0

[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

ANN: Cabal-1.16.0.2 and cabal-install-1.16.0.1
by Johan Tibell 24 Oct '12

24 Oct '12

Hi, On behalf of the cabal contributors, I'm proud to announce bugfix releases of Cabal and cabal-install. Here's a complete list of changes since the last release: Since Cabal-1.16.0.1: * Bump Cabal version number to 1.16.0.2 * Fixed warnings on the generated Paths module. The warnings are generated by the flag '-fwarn-missing-import-lists'. Since cabal-install-1.16.0: * Have bootstrap.sh use Cabal-1.16.0.2 * Fix installing from custom folder on Linux (#1058) * Change bootstrap.sh to require Cabal >= 1.16 && < 1.18 * Bump cabal-install version number to 1.16.0.1 * Bump network dependency in bootstrap.sh to 2.3.1.1 * Fix compilation error * Disable setting the jobs: $nprocs line in default ~/.cabal config * Fix building cabal-install with ghc-6.12 and older I expect this to be the last release from the 1.16 branch. I intend to make another in about 3 months, or a bit sooner if the sandboxing work is ready earlier. Cheers, Johan

1 0

RE: deprecating
by Simon Peyton-Jones 23 Oct '12

23 Oct '12

| > It's an interesting question: does Rank2Types mean "I require at | > least | > rank-2 types" or "I only use rank-2 types"? | | I think it means "I require at least rank-2 types". | | To clarify, I think it's OK if a compiler accepts a program marked | "Rank2Types" and incorrectly not marked "RankNTypes" when it actually | requires rank-n types. In every other flag it means the reverse of this. For example if I say -XGADTs I mean "This program uses the GADT feature, and can be compiled by any program supporting GADTs. It does not use kind polymorphism or type families, and if it turns out that the program *does* use those features it should be rejected". So to accept a program with a rank-3 type with a flag saying Rank2Types would be, well, inconsistent. But someone said that foolish consistency is the hobgoblin of tiny minds, so if everyone things it's better to be inconsistent than to nudge package authors with deprecations, I can live with that. (But I still think it's strange to have deprecations but to treat them as errors. We could instead get rid of deprecations altogether and just say "oldFunction not in scope"!) I doubt this is worth more of our time. I'll just make Rank2Types and PolymorphicComponents a synonym for RankNTypes, and document that infelicity. Simon

1 0