- cabal-devel - Haskell.org

cabal sandbox and the dist directory
by Daniel Trstenjak 15 Aug '14

15 Aug '14

Hi, currently it's conceptually and practically a bit unpleasant, that the sandbox is a bit holey, because the 'dist' directory remains when deleting the sandbox. Is there a special reason for this behaviour? In the case of a sandbox, why is there a 'dist' directory at all, respectively why isn't it located inside of the '.cabal-sandbox' directory? Greetings, Daniel

3 3

HEADS UP: Running cabal install with the latest GHC
by Edward Z. Yang 13 Aug '14

13 Aug '14

Hey all, SPJ pointed out to me today that if you try to run: cabal install --with-ghc=/path/to/inplace/bin/ghc-stage2 with the latest GHC HEAD, this probably will not actually work, because your system installed version of Cabal is probably too old to deal with the new package key stuff in HEAD. So, how do you get a version of cabal-install (and Cabal) which is new enough to do what you need it to? The trick is to compile Cabal using your /old/ GHC. Step-by-step, this involves cd'ing into libraries/Cabal/Cabal and running `cabal install` (or install it in a sandbox, if you like) and then cd'ing to libraries/Cabal/cabal-install and cabal install'ing that. Cabal devs, is cutting a new release of Cabal and cabal-install in the near future possible? In that case, users can just cabal update; cabal install cabal-install and get a version of Cabal which will work for them. Cheers, Edward

3 5

Fw: cabal-install-latest is not pointing to latest release
by Konrad Gądek 30 Jul '14

30 Jul '14

Hi, It seems that http://www.haskell.org/cabal/release/cabal-install-latest/ is pointing to cabal-install-1.20.0.1 while there is 1.20.0.3 already — is this a "whoopsie" or is there a reason for this? -- Konrad Gądek

3 5

Killing or resurrecting version tags for good
by Edward Z. Yang 26 Jul '14

26 Jul '14

Hello all, A while back, I was nattering around the parsing code for Cabal, and I noticed that Cabal still had code for parsing version tags, but was explicitly *not* printing out version tags. I proposed that we should get rid of the parsing code as well, but when I mentioned this on #ghc Mark Lentczner (cc'ed) mentioned that they were using version tags to identify different versions during a build, e.g. what Git version things correspond to. I am not going to claim to know the right answer to this question, but in either case, it is terrible that we are PARSING tags but not PRINTING them. This leads to terrible error messages, among other things, such as in this case: $ ghc-pkg describe json-0.7-foo ghc-pkg: cannot find package json-0.7 (NB: json-0.7 is installed.) So if we're keeping tags around, at least for the immediate future, then we should print them; otherwise, we should get rid of them entirely! Edward

2 2

[PATCH] Print a more friendly message when http_proxy is down.
by Nikita Karetnikov 26 Jul '14

26 Jul '14

An attempt to fix #1962. I think the exception comes from ‘connect’ in ‘Network.Socket’. I doubt that the proposed error message is friendly enough. Ideas? Also, can ‘handleJust’ catch ‘IOException’s that are not related to http_proxy?

3 4

[PATCH] Change 'whenCacheOutOfDate' to use '>' again.
by Nikita Karetnikov 25 Jul '14

25 Jul '14

As some of you may know, I’m trying to make ‘cabal install’ verify OpenPGP signatures that come from Hackage. I modified ‘updatePackageIndexCacheFile’ to ask whether a certain OpenPGP public key should be trusted, but I later discovered that the mentioned function is called twice during ‘cabal update’*, which means that all questions are also asked twice. I believe this doesn’t affect #1443 anymore. If so, please apply the attached patch. * ‘update’ uses ‘updateRepo’ and ‘checkForSelfUpgrade’. The former runs ‘updatePackageIndexCacheFile’ via ‘updateRepoIndexCache’. The latter calls ‘updatePackageIndexCacheFile’ via a sequence of calls from ‘getSourcePackages’ to ‘getSourcePackages’’ to ‘readRepoIndex’ to ‘whenCacheOutOfDate’.

2 3

Removing GHC's dependency on Cabal
by Edward Z. Yang 24 Jul '14

24 Jul '14

Hello all, I know Duncan and SPJ have been keen on removing GHC's dependency on Cabal for some time now. Simon and I were chatting about the subject today, and we wanted to propose an alternative way of doing the remodularization. Here are diagrams of the proposals: http://web.mit.edu/~ezyang/Public/ghc-cabal-refactor.pdf As I understand it, Duncan's proposal is to take the current constellation of libraries, and just remove the dependency to Cabal from GHC and bin-package-db, duplicating data structures as necessary. ghc-pkg is now responsible for converting between Cabal's format and GHC's format. Simon suggested that this 'ghc-pkg' functionality (which specifies the database format and how to handle it) should be placed in a library of its own. So in the third graph, we have a new package ghc-db which everyone depends on. Cabal no longers shells out to ghc-pkg to modify database, instead it directly converts to ghc-db's format and then invokes library functions in the library. We were wondering if there was any reason to prefer the former situation over the latter. One answer might be that Cabal is less keen to have a dependency on a very GHC specific library (although the ghc-pkg dependency is quite a fairly tightly coupled one.) Cheers, Edward

6 8

Re: Enhancement: Default cabal to `-p` profiling enabled
by Johan Tibell 24 Jul '14

24 Jul '14

It will be less painful to enable profiling by default when someone finishes the parallel build support for profiling "ways". That would mean that we can build the vanilla and profiling version of a library at the same time, saving quite a bit of time.

1 0

Multi-instance packages status report
by Edward Z. Yang 21 Jul '14

21 Jul '14

Hello all, As you may have noticed, I've been knocking around GHC and Cabal the past few weeks. One of the tasks that has been on my list is essentially reimplementing Philipp Schuster's 2012 GSoC, with a few small but important architectural differences. Here is a status report of what is going on. In my copy of GHC and Cabal [1,2], you can now install multiple copies of a package with differing dependencies to the package database, i.e. q-1.0 compiled against p-1.0, and against p-2.0. The packages in the database are distinguished via a *package key*, which is an md5 hash of the package id (e.g. q-1.0) and the sorted list of the package IDs of the transitive closure of dependencies (e.g. p-1.0 or p-2.0). The package key is used to generate linker symbols for packages, so it's possible to link together both copies of q in the same program, as long as you rename the modules appropriately (of course, the redefined types are considered unequal). When registering a package, ghc-pkg now checks and removes duplicate package keys, as opposed to package IDs. I've also implemented many of the necessary niceties for making it pleasant to deal with duplicated package IDs: for example, GHC's output logic has been adjusted to only qualify a package ID with the package key when there are multiples of the same package ID exposed in the database. I've also adjusted GHC's build system to use package keys rather than package IDs to refer to packages when building. Like the original GSoC project, we still need to have decisions on some of the major design choices. I think the most pressing one is "simplistic dependency resolution" when you use, e.g. ghc -package foo-1.0 or ./Setup configure --with-constraint="foo==1.0". Right now, I pick dependencies in an unspecified manner, check if they are consistent, and bail out if they are not. As it turns out, both GHC and ./Setup configure will already compute the transitive closure of dependencies, so I suspect we might be able to do something clever here. Less pressing but eventually necessary is clueing in cabal-install. Comments would be especially appreciated. Cheers, Edward [1] https://phabricator.haskell.org/D80 [2] https://github.com/haskell/cabal/pull/2002

1 0

Heads up: Updating Cabal pointer to Cabal HEAD
by Edward Z. Yang 18 Jul '14

18 Jul '14

Hello folks, In the interest in as small changes as possible, I am planning on updating the version Cabal we're tracking against to Cabal HEAD (after my build finishes validating, that is!) At a later point, when someone finally merges https://github.com/haskell/cabal/pull/1991 I'll make a smaller bump. I'll also file a bug on GHC Trac milestoned for 7.10 to make sure we get a new Cabal release before next release. Edward Excerpts from Edward Z. Yang's message of 2014-07-03 14:45:02 +0100: > Hello all, > > I am working on module reexports (https://ghc.haskell.org/trac/ghc/ticket/8407) > and this functionality requires concurrent changes to GHC and Cabal. > However, GHC is currently tracking 1.20, but Cabal HEAD has marched on. > > My question is, if I am to do this development on HEAD, what is the > standard operating procedure for retargeting GHC to a recent version of > Cabal? Of course I have to go and validate the build, but are there > any other considerations? Is this recorded anywhere? > > Thanks, > Edward

1 0