- cabal-devel - Haskell.org

Cabal-1.16.0.1 and cabal-install-1.16.0 release candidates
by Johan Tibell 01 Oct '12

01 Oct '12

Hi all, Bryan and I have spent the evening preparing and testing Cabal and cabal-install release candidates. We've tested the releases with the last 3 GHC release, on Linux, OS X, and Windows and using a largish set of commonly used packages (about 136 of them). If you'd like to help out with the testing, install the release candidates and then build your favorite packages in configurations you care about (e.g. with profiling enabled). To install the release candidates run: cabal install http://johantibell.com/files/Cabal-1.16.0.1.tar.gz http://johantibell.com/files/cabal-install-1.16.0.tar.gz Unless there are any issues, we'll make a release in the next few days. P.S. Don't miss the new -j option for building stuff in parallel. Cheers, Johan

1 0

patch applied (hackage-server): "Fix copy'n'paste typo in tags feature, it was opening the wrong db file"
by devnull＠community.haskell.org 28 Sep '12

28 Sep '12

Fri Sep 28 16:45:01 BST 2012 Duncan Coutts <duncan(a)well-typed.com> * Fix copy'n'paste typo in tags feature, it was opening the wrong db file Ignore-this: 4daa92e6ae995ee5d7e24e023c22fafc M ./Distribution/Server/Features/Tags.hs -1 +1

1 0

patch applied (hackage-server): "Step towards greater encapsulation and modularity of the feature modules" and 4 others
by devnull＠community.haskell.org 28 Sep '12

28 Sep '12

Thu Sep 27 22:38:03 BST 2012 Duncan Coutts <duncan(a)well-typed.com> * Step towards greater encapsulation and modularity of the feature modules Ignore-this: 2a79f6a60fdf42be6166a261d3a54de4 The Distribution.Server.Feature.* modules are the way we add functionality to the hackage server in a nice modular way. For this to be robust, these features need to properly encapsulate the state they manage, and provide APIs for other features to use that state in disciplined ways. Currently the AcidState stuff is global, rather than partitioned between features. This is primarily for historical reasons (the original happstack-state forced the state to be application global), and for ease of porting to the new acid-state package, we kept the same pattern of global shared state (in the Distribution.Server.Acid module). Obviously we want to split this up so that each feature encapsulates its own state. The first step to doing this more easily is to change the features to use a "first class module" style, where all the exported functions are part of a feature record. This will make things much easier since as we will not need to pass state tokens around to every query or update. e.g instead of: foo :: UsersFeature -> ... foo usersF ... = ... users <- queryGetUsersDb usersF it'll be simply foo :: UsersFeature -> foo UsersFeature{..} ... = users <- queryGetUsersDb And indeed, most functions don't need to take the feature arguments explicitly, just the top level initBlahFeature functions, with all other functions in the module defined in the where clause. This may seem a little odd, but in my experiments in trying to encapsulate the state properly, this seems like the best approach. M ./Distribution/Server/Features.hs -10 +14 M ./Distribution/Server/Features/BuildReports.hs -91 +91 M ./Distribution/Server/Features/Check.hs -174 +185 M ./Distribution/Server/Features/Core.hs -209 +227 M ./Distribution/Server/Features/Distro.hs -53 +55 M ./Distribution/Server/Features/Documentation.hs -55 +56 M ./Distribution/Server/Features/DownloadCount.hs -31 +35 M ./Distribution/Server/Features/HaskellPlatform.hs -12 +22 M ./Distribution/Server/Features/Html.hs -762 +763 M ./Distribution/Server/Features/Mirror.hs -49 +72 M ./Distribution/Server/Features/NameSearch.hs -38 +42 M ./Distribution/Server/Features/PackageContents.hs -33 +34 M ./Distribution/Server/Features/PackageList.hs -51 +58 M ./Distribution/Server/Features/Packages.hs -5 +6 M ./Distribution/Server/Features/PreferredVersions.hs -131 +139 M ./Distribution/Server/Features/ReverseDependencies.hs +1 M ./Distribution/Server/Features/ServerApiDoc.hs -4 +4 M ./Distribution/Server/Features/Tags.hs -72 +89 M ./Distribution/Server/Features/Upload.hs -203 +241 M ./Distribution/Server/Features/Users.hs -316 +370 M ./Distribution/Server/Users/State.hs -11 +1 Thu Sep 27 23:17:08 BST 2012 Duncan Coutts <duncan(a)well-typed.com> * Add checkpoint and shutdown to feature interface Ignore-this: 85c45148ef67dc5bff42b65c389ac1e1 and start to use it in the server checkpoint and shutdown. Eventually the global startAcid/stopAcid will go away. M ./Distribution/Server.hs -2 +7 M ./Distribution/Server/Features.hs +6 M ./Distribution/Server/Framework/Feature.hs +4 Thu Sep 27 23:24:00 BST 2012 Duncan Coutts <duncan(a)well-typed.com> * Convert UserFeature to encapsulating its state Ignore-this: e95e7ec792edc773acb235b6f4e38146 It manages the set of users and the admin user group M ./Distribution/Server.hs -13 +17 M ./Distribution/Server/Acid.hs -25 +9 M ./Distribution/Server/Features.hs -2 +2 M ./Distribution/Server/Features/BuildReports.hs -5 +4 M ./Distribution/Server/Features/Check.hs -2 +1 M ./Distribution/Server/Features/Core.hs -10 +5 M ./Distribution/Server/Features/Html.hs -5 +4 M ./Distribution/Server/Features/Mirror.hs -4 +4 M ./Distribution/Server/Features/Packages.hs -3 +2 M ./Distribution/Server/Features/Upload.hs -7 +6 M ./Distribution/Server/Features/Users.hs -31 +67 M ./Distribution/Server/Users/Backup.hs -16 +14 Fri Sep 28 03:30:08 BST 2012 Duncan Coutts <duncan(a)well-typed.com> * Massage the feature modules to follow a common pattern Ignore-this: ca490df4714b9c892e14232f0d6d1d04 This is partly intended to clarify what mutable state each module owns. We separate the initBlahFeature which creates the state, from a pure blahFeature function which is the module functor, that is it defines the behaviour for the new BlahFeature record in terms of the records of the imported modules, and the local private state. Sometimes these two parts are mutually dependent, in which case we use recursive do. M ./Distribution/Server/Features/BuildReports.hs -33 +47 M ./Distribution/Server/Features/Check.hs -6 +8 M ./Distribution/Server/Features/Core.hs -3 +3 M ./Distribution/Server/Features/Distro.hs -11 +23 M ./Distribution/Server/Features/Documentation.hs -40 +49 M ./Distribution/Server/Features/DownloadCount.hs -39 +52 M ./Distribution/Server/Features/HaskellPlatform.hs -18 +20 M ./Distribution/Server/Features/Html.hs -42 +75 M ./Distribution/Server/Features/Mirror.hs -2 +4 M ./Distribution/Server/Features/NameSearch.hs -37 +51 M ./Distribution/Server/Features/PackageContents.hs -27 +38 M ./Distribution/Server/Features/PackageList.hs -57 +78 M ./Distribution/Server/Features/Packages.hs -21 +42 M ./Distribution/Server/Features/PreferredVersions.hs -33 +43 M ./Distribution/Server/Features/ReverseDependencies.hs -30 +46 M ./Distribution/Server/Features/Tags.hs -3 +3 M ./Distribution/Server/Features/Upload.hs -3 +3 M ./Distribution/Server/Features/Users.hs -3 +3 Fri Sep 28 10:16:26 BST 2012 Duncan Coutts <duncan(a)well-typed.com> * Make the TagsFeature encapsulate its state Ignore-this: 8e92f0f5d962aa2580a274a93b416d4c M ./Distribution/Server/Acid.hs -12 +1 M ./Distribution/Server/Features/Html.hs -3 +3 M ./Distribution/Server/Features/PackageList.hs -2 +2 M ./Distribution/Server/Features/Tags.hs -16 +45 M ./Distribution/Server/Packages/Backup/Tags.hs -7 +7

1 0

A change in Git tag naming
by Johan Tibell 27 Sep '12

27 Sep '12

Hi, Since Cabal and cabal-install might not be released at the same time and thus not from the same Git commit we will from now on tag releases in the Git repo as Cabal-vX.Y.Z and cabal-install-vX.Y.Z The "v" in the tag is used to distinguish the tags from branches we might create some time before a release. Such branches would be named e.g. Cabal-1.16. to keep track of what was actually released. -- Johan

1 0

Re: [Hackage] #517: make cabal install command support haddock options
by Hackage 23 Sep '12

23 Sep '12

#517: make cabal install command support haddock options ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: reopened Priority: normal | Milestone: cabal-install-0.14.2 Component: cabal-install tool | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: | Platform: ---------------------------------+------------------------------------------ Changes (by nh2): * cc: mail@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/517#comment:21> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

patch applied (hackage-server): "Tweak dependencies" and 1 others
by devnull＠community.haskell.org 21 Sep '12

21 Sep '12

Thu Sep 20 21:29:06 BST 2012 Duncan Coutts <duncan(a)well-typed.com> * Tweak dependencies Ignore-this: c11b85c2e6eddddf32a87ec393c63803 M ./hackage-server.cabal -7 +8 Thu Sep 20 21:28:44 BST 2012 Duncan Coutts <duncan(a)well-typed.com> * Add a feature to show the server REST API Ignore-this: 1e622f725d03e2809234e547391c9f63 M ./Distribution/Server/Features.hs +2 A ./Distribution/Server/Features/ServerApiDoc.hs M ./Distribution/Server/Framework/ResourceTypes.hs +5 M ./static/hackage.css +1

1 0

testing cabal-install-0.25.2 with ghc-7.6.1
by Jens Petersen 18 Sep '12

18 Sep '12

Hi, I managed to build cabal-install-0.25.2 (from the cabal-1.16 branch) with ghc-7.6.1 Cabal. However the use of viewAsFieldDescr in cabal-install/Distribution/Client/Config.hs causes problems due to the: error "Command.optionToFieldDescr: feature not implemented" in Cabal-1.16.0, so I am not able to use cabal-install yet: $ cabal install cabal: Command.optionToFieldDescr: feature not implemented Jens

3 4

Re: [Haskell] Hackage2 server testing
by Ian Lynagh 13 Sep '12

13 Sep '12

On Mon, Sep 10, 2012 at 09:55:30AM +0200, Henning Thielemann wrote: > > Next test: I have successfully uploaded a package candidate of > 'gnuplot'. Now I go to the gnuplot candidate page and click on > [maintain]. Then I get a new page with the text "Here, you can > delete a candidate, publish it, upload a new one, and edit the > maintainer group". Below this text the page is empty. Above this > text there are the usual hackage navigation links. It does not look > like a can do a lot with the package candidate so far. Hackage people, what's the plan here? My assumption was that "Upload a package candidate" in Hackage 2 was just meant to check for problems in the package (which AFAIK is what "Checking a Cabal package" does in Hackage 1). It looks like more functionality might be planned, but not implemented? Should we just remove the "maintain" link for now? Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

3 5

Unallocated names
by Leon Smith 11 Sep '12

11 Sep '12

Ok, when I upload a package it warns me about unallocated names? How are names allocated, and who makes the decisions here? Best, Leon

5 9

patch applied (hackage-server): "Add a comment"
by devnull＠community.haskell.org 11 Sep '12

11 Sep '12

Tue Sep 11 22:05:28 BST 2012 Ian Lynagh <ian(a)well-typed.com> * Add a comment Ignore-this: f597f4a436c0af72d022916bea3ff85c M ./tests/HighLevelTest.hs +1

1 0