October 2011 - cabal-devel

patch applied (hackage-server): "Update dependencies so that it builds on ghc-7.2.1" and 2 others
by duncan＠lun.haskell.org 23 Oct '11

23 Oct '11

Thu Oct 20 21:36:13 BST 2011 Bas van Dijk <v.dijk.bas(a)gmail.com> * Update dependencies so that it builds on ghc-7.2.1 Ignore-this: b23effb8571e3de4d3310e37a2c5b81f It also requires a patched rss which is not yet released M ./Distribution/Server/Pages/Recent.hs -7 +3 M ./hackage-server.cabal -5 +5 Sun Oct 23 14:03:57 BST 2011 Duncan Coutts <duncan(a)well-typed.com> * Drop dependency on old-time Ignore-this: 5f59217f285c83117fa3f6d3e11bdd46 M ./Distribution/Server/Pages/Recent.hs -2 +1 M ./hackage-server.cabal -3 Sun Oct 23 14:05:04 BST 2011 Duncan Coutts <duncan(a)well-typed.com> * Allow building with older containers and deepseq Ignore-this: 837646be45f1000f2f8c8a8cc5e07f90 So it builds ok with the versions that come with ghc-6.12 and 7.0 M ./hackage-server.cabal -2 +15

1 0

patch applied (/home/srv/code/hackage-server): "crypt is not thread-safe so synchronize acces to it using a lock (MVar ())."
by duncan＠lun.haskell.org 22 Oct '11

22 Oct '11

Sat Oct 22 14:36:25 BST 2011 Bas van Dijk <v.dijk.bas(a)gmail.com> * crypt is not thread-safe so synchronize acces to it using a lock (MVar ()). Ignore-this: f322b7b456cd0db8d146397252a8e979 M ./Distribution/Server/Framework/AuthCrypt.hs -1 +7

1 0

Cabal plugins
by Antoine Latter 21 Oct '11

21 Oct '11

On Fri, Oct 21, 2011 at 3:49 PM, Jason Dagit <dagitj(a)gmail.com> wrote: > On Fri, Oct 21, 2011 at 1:29 PM, Brent Yorgey <byorgey(a)seas.upenn.edu> wrote: >> Hi everyone, >> >> I'm working on some improvements to 'cabal init', the biggest of which >> is looking at imports in source files to guess an initial list of >> dependencies to populate the 'Build-depends:' field. I wanted to get >> some feedback on a design decision: what to do when we find multiple >> packages providing the same module? > > While cabal init is something I use, I would prefer to have a separate > tool for calculating my build-depends field. Something that could > suggest things for an existing cabal project, ideally. Then I could > run that regularly during development to help me determine what my > build-deps should be and cabal init could suggest I run it (or run it > for me). > > While I'm suggesting features I would like, wouldn't it be great if > cabal used the plugin RFC that Simon came up with? > http://www.mail-archive.com/haskell-cafe@haskell.org/msg92770.html > > I think that interface is a great way to unify the tools that have > sprung up around cabal such as cabal-dev and cab. > One thing that will be hard for plugins is that there's no way to get at the package hooks without entering through Setup.main. This means that if your plugin wants to, say, call haddock with slightly tweaked arguments, you might miss something important that the standard 'cabal haddock' would have gotten because it runs the user hooks. (This concern only applies if your plugin is using the Cabal library to open up the package description and root around and do things). There's probably still a lot you can do, though - something like 'cabal-dev' could be entirely written as a plugin (and I guess it would be out-of-the-box: 'cabal dev configure' would 'just work' under this proposal, although the help text would need to change). Antoine

1 0

Dependency guessing for cabal init
by Brent Yorgey 21 Oct '11

21 Oct '11

Hi everyone, I'm working on some improvements to 'cabal init', the biggest of which is looking at imports in source files to guess an initial list of dependencies to populate the 'Build-depends:' field. I wanted to get some feedback on a design decision: what to do when we find multiple packages providing the same module? Suppose we find a source file with the line import Foo.Bar So we get the list of installed packages, and look for packages providing the Foo.Bar module. If there's only one, great! We just use that version of that package as a dependency (with a conservative upper bound guided by the PVP). However, I suspect that much of the time we will instead find something like this: Scenario A: foobar-0.3 foobar-0.4 foobar-0.4.1 Scenario B: foobar-0.3 wizbang-0.4 all providing Foo.Bar. In Scenario A, which do we pick as our dependency: (a) foobar >= 0.3 && < 0.5 (b) foobar >= 0.4 && < 0.5 (c) foobar >= 0.4.1 && < 0.5 Personally, I lean towards (b): the earliest version PVP-compatible with the latest available version. But I could in principle be convinced of any of these options. In Scenario B, do we: (a) arbitrarily pick a package (and generate a warning) (b) refuse to pick either package (and generate a warning)? (c) pick *both* and let the user clean up the mess later (and generate a warning)? I suppose (b) seems most sensible. It's possible no one really cares and it doesn't matter that much, which is also fine. =) -Brent

2 1

Two patches for hackage-server
by Bas van Dijk 20 Oct '11

20 Oct '11

Hi Duncan, as promised attached is the patch that turns crypt into a safe ccall. Also attached is a patch that updates hackage-server to the latest versions of its dependencies. This enables it to build on ghc-7.2.1. I also depend on a new unreleased version of rss. I also attached this patch for rss. I'm currently looking for the new maintainer of rss (Bjorn Bringert doesn't maintain it anymore). If nobody steps up, I will take it over. Regards, Bas

1 0

patch applied (/home/srv/code/hackage-server): "Link with the crypt lib"
by duncan＠lun.haskell.org 20 Oct '11

20 Oct '11

Thu Oct 20 21:19:24 BST 2011 Duncan Coutts <duncan(a)well-typed.com> * Link with the crypt lib Ignore-this: d20e90b6668040dcfebc462933dff14d Except on OSX where it's in libc. M ./hackage-server.cabal +3

1 0

patch applied (/home/srv/code/hackage-server): "Tidy up the runServerPartT_hack" and 1 others
by Max Bolingbroke 19 Oct '11

19 Oct '11

Wed Oct 19 07:49:26 BST 2011 Max Bolingbroke <batterseapower(a)hotmail.com> * Tidy up the runServerPartT_hack Ignore-this: aa344978763ecd1d905d6c921d78d03 M ./Distribution/Server/Util/Happstack.hs -16 +8 Wed Oct 19 09:52:16 BST 2011 Max Bolingbroke <batterseapower(a)hotmail.com> * Serve a plain text password upgrade message to cabal-install clients Ignore-this: dff158eb8baaad66b9b5064afd2c54af M ./Distribution/Server/Framework/Auth.hs -18 +24 M ./Distribution/Server/Util/ContentType.hs -12 +18

1 0

Mirroring package uploader/upload date
by Max Bolingbroke 18 Oct '11

18 Oct '11

Fellow members of the shadowy Cabal, I've been looking at making the mirror client supply the original uploading user/upload time when it mirrors a package. I've developed an approach (attached) that, rather than PUTting a simple tarball to mirror, PUTs a combination of the tarball, user name and upload date in multipart/form-data format. This works (though the code is a bit grungy still). The only thing I'm worrying about before I tidy it up and commit is whether it is sufficiently RESTful: it feels a bit weird that the thing that you PUT is not what you get back from making a GET request to that URL. An alternative approach would be to expose resources for the uploader/upload time of a package, which the mirror client could then simply PUT to. Anyone have any thoughts on the right approach here? Max

2 2

patch applied (/home/srv/code/hackage-server): "Add FIXME" and 3 others
by Max Bolingbroke 18 Oct '11

18 Oct '11

Tue Oct 18 22:23:12 BST 2011 Max Bolingbroke <batterseapower(a)hotmail.com> * Add FIXME Ignore-this: 9de57a0e0cbcecd81b57a4be71980b57 M ./Distribution/Server/Framework/Auth.hs +1 Tue Oct 18 22:35:36 BST 2011 Max Bolingbroke <batterseapower(a)hotmail.com> * Add URLs mirrorers can use to PUT/GET the upload time Ignore-this: 14c00e2e19c7050a93a20731a52c7ce6 M ./Distribution/Server/Features/Mirror.hs -2 +27 M ./Distribution/Server/Packages/State.hs +12 Tue Oct 18 22:47:59 BST 2011 Max Bolingbroke <batterseapower(a)hotmail.com> * Add URL to allow an uploader to be PUT to the server Ignore-this: 2cb926008b4593c9f1ba2d33fbac7534 M ./Distribution/Server/Features/Mirror.hs -4 +19 M ./Distribution/Server/Packages/State.hs -5 +11 Tue Oct 18 22:57:40 BST 2011 Max Bolingbroke <batterseapower(a)hotmail.com> * Have the mirror client PUT uploader/upload time if available Ignore-this: ed5580492a68dec97e7d7068f25bc3f3 M ./MirrorClient.hs -14 +22

1 0

Re: [Hackage] #626: Package build error due to unicode
by Hackage 18 Oct '11

18 Oct '11

#626: Package build error due to unicode ----------------------------+----------------------------------------------- Reporter: basvandijk | Owner: Type: defect | Status: reopened Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Resolution: Keywords: | Difficulty: unknown Ghcversion: | Platform: ----------------------------+----------------------------------------------- Comment(by nomeata): Hmm, this write the prologue, but then haddock fails with the same error. http://www.haskell.org/haddock/doc/html/ch03s08.html Says that Unicode characters should be escaped. So I guess this should happen here as well. Or just haddock be made unicode aware... -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/626#comment:5> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0