August 2012 - cabal-devel

Load path environment variable for cabal sources?
by Tim Cuthbertson 04 Aug '12

04 Aug '12

Hi all, I've done some digging into distributing haskell libraries outside of cabal/hackage, using zeroinstall (http://0install.net) My current results distributing compiled libraries have been somewhat fragile, due to having no good way of tracking changes to the GHC abi and forcing a rebuild of libraries when mismatches are found. I don't at this point care for distributing binary-only libraries, that is just how zeroinstall likes to work (compile all dependencies into a usable binary form, then compile the program that depends on them). I'm wondering if the problem could be worked around by only ever distributing libraries as source-only, and just statically linking programs (which I believe is the default already). This would lead to too much compilation since already-compiled libraries would not be used, but that's better than it not working as soon as GHC is upgraded (which I believe is my current status). When distributing precompiled libraries, I've been adding them to GHC_PKG_PATH - `cabal build` will then use these binaries to satisfy dependencies of the app I'm building. What I would like is for the same mechanism, but for sources instead of precompiled binaries. I have a working cut of this after some hacking, which basically involves: - putting all dependencies' source directories into a colon-separated environment variable, "CABAL_PKG_PATH" (this is how zeroinstall typically makes dependancies available) - Creating a temporary cabal config file that specifies a single `local-repo` location inside the (throwaway) build dir - populating said local-repo folder, by traversing each path in $CABAL_PKG_PATH and: - find the cabal file in each directory - extract important metadata (name and version) from the cabal file - add the cabal file to 00-index.tar as {name}/{version}/{name}.cabal - tarring up the source directory and placing it under {name}/{version}/{name}-{version}.tar.gz - run `cabal install` from the program's source directory with $CABAL_CONF, --builddir and --prefix set appropriately Tarring up all source packages in particular seems fairly wasteful, and it all seems like quite a few hoops to jump through in order to construct something that looks like a hackage cache (which I don't particularly want, but it seems to be the only way to make them available). So I was wondering if there is any simpler way to populate a set of local sources such that `cabal install` will be able to find them? It's quite likely that it was never really intended to work with anything other than a hackage-style DB, but I thought it couldn't hurt to ask :) Cheers, - Tim.

1 0

patch applied (hackage-server): "Fix memory usage while mirroring"
by devnull＠community.haskell.org 01 Aug '12

01 Aug '12

Thu Aug 2 00:37:38 BST 2012 Ian Lynagh <ian(a)well-typed.com> * Fix memory usage while mirroring Ignore-this: 9faf4be0f646da02f2ac1a059488fd99 We were extracting the .cabal file from the .tar file, but the ByteString for the .cabal file was a portion of the ByteString for the .tar file, so the whole .tar file was being kept in memory. M ./Distribution/Server/Packages/Unpack.hs -1 +6

1 0

patch applied (hackage-server): "Fix space usage of constructImmutableTagIndex" and 1 others
by devnull＠community.haskell.org 01 Aug '12

01 Aug '12

Wed Aug 1 14:56:56 BST 2012 Ian Lynagh <ian(a)well-typed.com> * Fix space usage of constructImmutableTagIndex Ignore-this: 5bf147a17b68fb2a140ff36fe0255e5a M ./Distribution/Server/Features/Tags.hs -4 +11 Wed Aug 1 15:02:26 BST 2012 Ian Lynagh <ian(a)well-typed.com> * Fix space usage of constructItemIndex Ignore-this: ae916b04da48e12d8772d0ca4f5b0dc8 M ./Distribution/Server/Features/PackageList.hs -8 +8

1 0

patch applied (hackage-server): "Fix space usage of packageIndex"
by devnull＠community.haskell.org 01 Aug '12

01 Aug '12

Wed Aug 1 14:45:35 BST 2012 Ian Lynagh <ian(a)well-typed.com> * Fix space usage of packageIndex Ignore-this: 6581f5c82e02b3f7ca9ddb9dfe876034 It was keeping the whole PackageDescription for all packages in memory at once. M ./Distribution/Server/Pages/Index.hs -12 +30

1 0

patch applied (hackage-server): "Fix whitespace, and enable -fwarn-tabs"
by devnull＠community.haskell.org 01 Aug '12

01 Aug '12

Wed Aug 1 14:10:24 BST 2012 Ian Lynagh <ian(a)well-typed.com> * Fix whitespace, and enable -fwarn-tabs Ignore-this: 1fd465082a66be88b4b42c458582dc84 M ./Distribution/Server/Features/Packages.hs -2 +2 M ./Distribution/Server/Features/Users.hs -1 +1 M ./Distribution/Server/Pages/Index.hs -70 +70 M ./Distribution/Server/Pages/Package.hs -9 +9 M ./Distribution/Server/Pages/Package/HaddockHtml.hs -24 +24 M ./Distribution/Server/Pages/Recent.hs -6 +6 M ./Distribution/Server/Pages/Template.hs -7 +7 M ./hackage-server.cabal -3 +4

1 0

patch applied (hackage-server): "Remove the pkgDesc field from PkgInfo" and 1 others
by devnull＠community.haskell.org 01 Aug '12

01 Aug '12

Wed Aug 1 12:16:49 BST 2012 Ian Lynagh <ian(a)well-typed.com> * Remove the pkgDesc field from PkgInfo Ignore-this: 4bc99b4d21e7396e0840598774b424d8 This should reduce the memory usage of the server M ./Distribution/Server/Features/Check.hs -1 M ./Distribution/Server/Features/Mirror.hs -2 M ./Distribution/Server/Features/Upload.hs -1 M ./Distribution/Server/LegacyImport/BulkImport.hs -2 +1 M ./Distribution/Server/Packages/Backup.hs -2 +1 M ./Distribution/Server/Packages/State.hs -1 M ./Distribution/Server/Packages/Types.hs -7 +11 M ./Distribution/Server/Pages/Index.hs -1 +1 M ./Distribution/Server/Pages/Recent.hs -5 +3 Wed Aug 1 12:21:57 BST 2012 Ian Lynagh <ian(a)well-typed.com> * Don't link with -rtsopts Ignore-this: f839329120673e799b59f17acfc3c7d It makes the server vulnerable by default M ./hackage-server.cabal -1 +1

1 0

Added a build bot for Cabal
by Johan Tibell 01 Aug '12

01 Aug '12

Hi all, Prompted by a regression due the GhcOptions refactoring (which was otherwise great) I've created a build bot for Cabal in hope to encourage people to add unit tests. The build bot lives on my VPS here: http://ci.johantibell.com/ I've set up the build bot to send an email to this mailing list if any tests start failing. Please add more tests! P.S. I had to disable two unit tests that have been failing for ages to get the build bot up and running. -- Johan

2 1