- cabal-devel - Haskell.org

patch applied (hackage-server): "Support alex >= 3" and 2 others
by devnull＠community.haskell.org 20 Nov '12

20 Nov '12

Mon Nov 12 13:40:07 GMT 2012 Edsko de Vries <edsko(a)well-typed.com> * Support alex >= 3 Ignore-this: 9cc786fe9919abdfb0d4e62bdebe1e0a M ./Distribution/Server/Pages/Package/HaddockLex.x +12 M ./hackage-server.cabal -1 +1 Tue Nov 20 11:35:23 GMT 2012 Edsko de Vries <edsko(a)well-typed.com> * Remove bounds on Cabal for test Ignore-this: b92e73f8c90ef9610f1d4646f4242705 The bounds that were there were incompatible with the bounds on the main package M ./hackage-server.cabal -1 +1 Tue Nov 20 11:50:48 GMT 2012 Edsko de Vries <edsko(a)well-typed.com> * Add human readable description to features and resources Ignore-this: 705688fd79082b6dd92e959b400abd52 M ./Distribution/Server/Features/ServerApiDoc.hs -2 +7 M ./Distribution/Server/Framework/Feature.hs +2 M ./Distribution/Server/Framework/Resource.hs -7 +9

1 0

Reinstalling a package + all its reverse dependencies
by Mikhail Glushenkov 17 Nov '12

17 Nov '12

Hi all, While working on #1105 ("Rebuild source directories added to the sandbox"), I encountered a problem: there is no way to reinstall a bunch of packages + all their reverse dependencies. Right now when you run sandbox-build it does the following (see the cabal-sandbox branch in my repo [1]): cabal install /path/to/add-source-dep-1 ... /path/to/add-source-dep-N --force-reinstall && cabal build Unfortunately, this doesn't reinstall the reverse dependencies of add-source deps, which can obviously break them (hence the need for --force-reinstall). I tried several option combinations, but nothing gives me what I want. To solve this, I propose adding an option '--only-dependencies-of=TARGET' that would work like '--only-dependencies', but only remove TARGET from the install plan (see adjustOnlyDependencies in D.C.Install). This would make it possible to implement sandbox-build in the following fashion: cabal install /path/to/add-source-dep-1 ... /path/to/add-source-dep-N --only-dependencies-of=. && cabal build Comments? [1] https://github.com/23Skidoo/cabal/commits/cabal-sandbox -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

1 1

patch applied (hackage-server): "Extend the import client with support for several extra kinds of data" and 11 others
by devnull＠community.haskell.org 16 Nov '12

16 Nov '12

Wed Nov 7 22:27:50 GMT 2012 Duncan Coutts <duncan(a)well-typed.com> * Extend the import client with support for several extra kinds of data Ignore-this: b401cb6ebc46d75ab31f3a9605dbe4c6 Adjusting the maintainer group for packages, package tarballs, package deprecation information and distro info. ./ImportClient/BulkImport.hs -> ./ImportClient/PkgIndex.hs M ./ImportClient.hs -23 +252 A ./ImportClient/DistroMap.hs M ./ImportClient/HtPasswdDb.hs -2 +2 M ./ImportClient/PkgIndex.hs -166 +7 A ./ImportClient/TagsFile.hs M ./ImportClient/UploadLog.hs -2 +2 M ./hackage-server.cabal -6 +1 Fri Nov 9 15:31:12 GMT 2012 Duncan Coutts <duncan(a)well-typed.com> * Remove the legacy convert feature from the server Ignore-this: 79056f815ffa6625c28d14bf492e5d03 Instead of having the server do the legacy import direct into its database, we have an import client that does it all via the server's public http interface. M ./Distribution/Server.hs -83 +2 M ./Main.hs -115 +1 M ./hackage-server.cabal -6 Fri Nov 9 15:37:36 GMT 2012 Duncan Coutts <duncan(a)well-typed.com> * Move the legacy import format modules under the Client namespace Ignore-this: b05e3f35601270051294c08f55d5371a ./ImportClient -> ./Distribution/Client M ./Distribution/Client.hs -1 +1 M ./Distribution/Client/DistroMap.hs -2 +2 M ./Distribution/Client/HtPasswdDb.hs -1 +1 M ./Distribution/Client/PkgIndex.hs -2 +2 M ./Distribution/Client/TagsFile.hs -2 +2 M ./Distribution/Client/UploadLog.hs -1 +1 R ./Distribution/Server/LegacyImport/ R ./Distribution/Server/LegacyImport/BulkImport.hs R ./Distribution/Server/LegacyImport/HtPasswdDb.hs R ./Distribution/Server/LegacyImport/UploadLog.hs M ./ImportClient.hs -5 +5 M ./MirrorClient.hs -1 +2 Fri Nov 9 15:43:41 GMT 2012 Duncan Coutts <duncan(a)well-typed.com> * Allow building with ghc-7.6-compatible libs Ignore-this: 72bcbe4caf2a4497feaa81b84c408f6d M ./Distribution/Server/Framework/Instances.hs -1 +3 M ./hackage-server.cabal -6 +6 Fri Nov 9 18:21:52 GMT 2012 Duncan Coutts <duncan(a)well-typed.com> * Add basic server logging Ignore-this: ea5e1329858020508a91206a44f3046e Using -v will give an apache-style access log on stdout M ./Distribution/Server.hs -1 +20 M ./Main.hs -3 +14 M ./hackage-server.cabal -1 +2 Tue Nov 13 20:01:27 GMT 2012 Duncan Coutts <duncan(a)well-typed.com> * Allow maintainers to remove themselves and other members from the group Ignore-this: 65306e0bb4d35913dc13e1fa4d38e214 M ./Distribution/Server/Features/Upload.hs -1 +1 Tue Nov 13 20:02:34 GMT 2012 Duncan Coutts <duncan(a)well-typed.com> * Move the location of the package uploader and upload-time resources Ignore-this: b02c5b12dd28983d8a9d46b48be6c7b9 Rather than being under the tarball, they're under the package itself ie /package/edit-distance-0.2.1/upload-time rather than /package/edit-distance-0.2.1/edit-distance-0.2.1.tar.gz/upload-time This is useful because we want to be able to upload package metadata separately from uploading the package tarball. M ./Distribution/Server/Features/Mirror.hs -7 +17 M ./MirrorClient.hs -4 +4 Tue Nov 13 20:52:29 GMT 2012 Duncan Coutts <duncan(a)well-typed.com> * Add the appropriate GET/PUT/DELETE methods to the group resources Ignore-this: f7e3cce56ec037b69372afc30b90e74d Previously the group resources (admins, maintainers etc) had no methods except as provided by the html feature. Now you can GET the group info as json, and you can PUT/DELETE members of the group. This will be used by the import client. M ./Distribution/Server/Features/Users.hs -11 +78 Tue Nov 13 20:55:47 GMT 2012 Duncan Coutts <duncan(a)well-typed.com> * Update the import of upload and maintainer info Ignore-this: 78a2b6d47aad9bce40db8566e9141626 from the old hackage log file M ./Distribution/Client/UploadLog.hs -11 +31 M ./ImportClient.hs -10 +30 Tue Nov 13 21:18:30 GMT 2012 Duncan Coutts <duncan(a)well-typed.com> * Use -fno-warn-unused-do-bind Ignore-this: a7ce79337e7c7fb2b7554d0804d88931 M ./hackage-server.cabal -1 +1 Thu Nov 15 13:04:27 GMT 2012 Duncan Coutts <duncan(a)well-typed.com> * Add initial import-client support for uploading doc tarballs Ignore-this: 95e4257e7968f65c46fc41aa07f9d197 M ./ImportClient.hs +61 Fri Nov 16 14:28:29 GMT 2012 Duncan Coutts <duncan(a)well-typed.com> * Fix the distro import stuff Ignore-this: 9edc788c962f1675720aade3b739489e M ./Distribution/Client/DistroMap.hs -5 +3 M ./Distribution/Server/Features/Distro.hs -8 +33 M ./ImportClient.hs -1 +6

1 0

Status of cabal repl
by Johan Tibell 09 Nov '12

09 Nov '12

Hi Duncan, I'm trying to finalize the list of things to include in Cabal/cabal-install 1.18, which I hope to push out by the end of this year. What's the current status of the cabal repl work? Is it close enough to being finished for someone else to pick up and take the rest of the way? In my naive understanding of the problem, now when we have refactored the way we create GHC command line invocations and gotten the ghci changes into GHC, it should be as simple manner of creating the needed command line (similar to cabal build but with e.g. an --interactive in there) and invoke ghci. This is probably a bit naive so perhaps you could clarify what's needed? -- Johan

3 3

Integrating tools with Cabal
by Roman Cheplyaka 09 Nov '12

09 Nov '12

Hi, Suppose I have some kind of analysis tool that I want to run on a Cabal project. The analysis tool only deals with Haskell files, so I need Cabal to generate Haskell files from CPP-enabled Haskell files, .hsc files, alex and happy files etc. I see two possible ways to do that: use Cabal as a library, or my tool to be run by Cabal as a compiler. Cabal as a library doesn't seem friendly to this kind of usage: for example, Distribution.Simple does not export things like 'configureAction'. Besides, this wouldn't work with packages that use other build-types. Extending Cabal with a new compiler is not a simple thing, either (see https://github.com/haskell/cabal/issues/57) So, any advice how to proceed? I can volunteer to improve things if someone gives directions (I'm a Cabal noob). Roman

2 7

Cabalizing exclusively C projects
by Jurriaan Hage 06 Nov '12

06 Nov '12

Dear all, my situation is that I want to compile and install a certain C-executable through a .cabal file (no Haskell involved at all). It is part of a larger system that features a LOT of Haskell. I would like to be able to set the --prefix or the --bindir to some default from Cabal (i.e., not by setting it on the command line, but in some way from the cabal file itself). Do you know how this can be done? So that without worrying about it too much an executable will end up where by default normal executables compiled with the other build-types end up. I also found the following two issues: when doing a cabal install it complains at the end that cabal: /Users/jur/Library/Haskell/ghc-7.4.1/lib/lvmrun-1.0/bin: does not exist This is because the makefile does not install the executable there. Is this a bug? Can it be circumvented? I was also surprised to see that a package MUST be registered. Somewhere else I saw it that only libraries must be registered and lvmrun is only an executable. One more thing: when I execute cabal sdist Distribution quality errors: No 'Main-Is' field found for executable lvmrun Unknown compiler 'GCC' in 'tested-with' field. The 'license' field is missing or specified as AllRightsReserved. Packages using 'cabal-version: >= 1.10' must specify the 'default-language' field for each component (e.g. Haskell98 or Haskell2010). If a component uses different languages in different modules then list the other ones in the 'other-languages' field. Note: the public hackage server would reject this package. Warning: Cannot run preprocessors. Run 'configure' command first. ... Do you think uploading the Cabal file for a C-only distro is impossible? In the end, I may be better off rolling my own SetUp.hs. What do you think? Would that make it possible for Cabal to pass own the standard location for installing into the call to ./configure? Sorry for all these questions, but I do not see any way out at the moment. And I'd really like to see the Helium compiler on Hackage at some point. best, Jur

2 1

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