April 2013 - cabal-devel

darcs patch: Add a new checkout Command (and 1 more)
by Joachim Breitner 20 Jul '13

20 Jul '13

Hi, the small feature implemented by the attached patches could make it more convenient for people to quickly and easily contribute to hackage packages. Do you want me to open a ticket for this or can you appl yit right away? Thanks, Joachim 2 patches for repository http://darcs.haskell.org/cabal-install: Sun Nov 7 12:35:32 CET 2010 Joachim Breitner <mail(a)joachim-breitner.de> * Add a new checkout Command Given a package name, this uses the SourceRepo field of the newest versionf of that pacakge to figure out the repository location and calls the right VCS invocation. Sun Nov 7 12:43:35 CET 2010 Joachim Breitner <mail(a)joachim-breitner.de> * Add a --dry-run flag to cabal checkout

2 3

install --builddir
by Benjamin Scarlet 15 Apr '13

15 Apr '13

I'm having trouble with install --builddir. If I run $ cabal install --builddir /some/absolute/path test-framework I get an error after regex-posix is installed, during the build of test-framework: Text/Regex/Posix/Wrap.hsc:141:8: Could not find module `Text.Regex.Base.RegexLike' It is a member of the hidden package `regex-base-0.93.2'. Perhaps you need to add `regex-base' to the build-depends in your .cabal file. Use -v to see a list of the files searched for. But if I run $ cabal install --builddir /some/absolute/path regex-posix $ rm -r /some/absolute/path $ cabal install --builddir /some/absolute/path test-framework I do not get the error. Between experiments I'm removing my ~/.cabal and ~/.ghc and running cabal update. Naively, it looks to me like using an absolute builddir has changed things so successive packages share the same intermediate files, which in turn has caused a later package to erroneously recompile a previously generated file. My ultimate aim is only to be able to use cabal-dev for my development builds, but without writing into my source tree. Is there any way to specify a build directory outside the source of a package without it winding up shared? Could/should cabal instead create a separate subdirectory within the specified builddir for each package to be built, so that specifying an external location didn't break things? Thanks, Ben Scarlet

2 1

hackage 2: alpha testing, testers wanted!
by Duncan Coutts 15 Apr '13

15 Apr '13

Hi folks, I believe we're ready for alpha testing for hackage 2. The server is up at: http://new-hackage.haskell.org/ Key points: * All the old data is imported (including docs) * Uploading is enabled * Live mirroring is also enabled * Per-package maintainer groups are pre-populated * Existing users should be able to log in (after a one-time upgrade) I would like to invite everyone on this list to help out with the alpha testing and to report issues here on this list. Patches are even better. The server is up now so you'll get "instant patch gratification"tm if you chip in and fix things. In addition to any bugs you may discover, the server main page gives an overview of the features that are partially complete and could do with some love. When we're satisfied we'll move into beta testing and advertise more widely within the community (reddit etc). The doc builder is not set up yet, but the builder client code exists, just need to get that set up. In general the switch over plan remains that we run the two servers in parallel for long enough to sort out remaining issues (with help from the kind folks who volunteered as admins). Code and wiki ============= The code is all still in darcs. darcs get http://code.haskell.org/hackage-server/ The plan is to move it to github at some stage. The wiki content is still useful though starting to get a bit out of sync: http://hackage.haskell.org/trac/hackage/wiki/HackageDB/2.0 We had to turn off wiki editing for most users because of spammers. If you'd like to work on the wiki, let me know and I'll give your account permission to edit it. Note also that I think Ben Millwood is planning to move the content to github at some stage, though we can still make improvements to the content in the meantime. Hackage Admins ============== I believe the following people volunteered to be admins, at least for the alpha/beta testing period: * Erik Hesselink * Ben Millwood * Johan Tibell If you folks (or anyone else who wants to volunteer) would like to confirm that then I'll add you to the admins group. User accounts ============= Existing users should be fine. That process should now be fairly smooth (testing welcome!). For new users, they can sign up with email confirmation. An administrator is needed to add a user into the uploaders group. Currently there's not a lot you can do with an account if you're not in the uploaders group. That may change in future if we implement "social" features. Hackage Trustees ================ In addition to admins we have the "trustees" group. This should eventually be a rather useful job. The idea is that the trustees don't upload packages but look after the health of the package collection as a whole (or some subset they're interested in), a bit like distro maintainers. Currently they can only edit package tags and upload docs (e.g. if the doc builder fails) but the plan is for them (as well as maintainers) to be able to edit package metadata, in particular the constraints on dependencies. Once we get there, that'll be a rather important job. So I'm also looking for volunteers there, both to be trustees and to help finish implementing the metadata-editing feature. -- Duncan Coutts, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

3 4

Close to release candidate
by Johan Tibell 12 Apr '13

12 Apr '13

Hi all, Today I merged Mikhail's sandbox UI changes. I believe this is the biggest hurdle to get the next release out. We have a few remaining tickets: https://github.com/haskell/cabal/issues?milestone=20&state=open and then we should be good to go. I will start with #1106. I think we can punt on #1143. #1197 is important however. -- Johan

1 0

patch applied (hackage-server): "Remove the basic html package pages from the core and candidate features" and 4 others
by devnull＠community.haskell.org 08 Apr '13

08 Apr '13

Fri Mar 29 18:14:30 GMT 2013 Duncan Coutts <duncan(a)community.haskell.org> * Remove the basic html package pages from the core and candidate features Ignore-this: d1d21177dadd082d176d78130db247a2 M ./Distribution/Server/Features/Core.hs -39 +1 M ./Distribution/Server/Features/PackageCandidates.hs -20 +1 Sat Mar 30 08:50:03 GMT 2013 Duncan Coutts <duncan(a)community.haskell.org> * Simplify Hook interface and remove a few unused feature hooks Ignore-this: 66d7b02693ae0ee3168ca4f98fcdd17e M ./Distribution/Server/Features/Core.hs -36 +22 M ./Distribution/Server/Features/DownloadCount.hs -1 +1 M ./Distribution/Server/Features/Html.hs -4 +4 M ./Distribution/Server/Features/NameSearch.hs -6 +6 M ./Distribution/Server/Features/PackageCandidates.hs -31 +22 M ./Distribution/Server/Features/PackageList.hs -9 +9 M ./Distribution/Server/Features/PreferredVersions.hs -7 +7 M ./Distribution/Server/Features/RecentPackages.hs -1 +1 M ./Distribution/Server/Features/Tags.hs -4 +4 M ./Distribution/Server/Features/Upload.hs -15 +3 M ./Distribution/Server/Features/Users.hs -19 +7 M ./Distribution/Server/Framework/Hook.hs -46 +15 Mon Apr 8 22:08:11 BST 2013 Duncan Coutts <duncan(a)well-typed.com> * Change http code for the legacy passwd auth failure Ignore-this: cd56b7525cfaac2d5bba8c30ea17a3f2 When someone tries to authenticate for a user account that has a legacy password, we previously returned 401 without any auth methods. It turns out that returning 401 in this case is a violation of the http spec because you must provide at least one auth method. So change it to use 403 Forbidden. M ./Distribution/Server/Features/LegacyPasswds.hs -1 +1 Mon Apr 8 22:13:44 BST 2013 Duncan Coutts <duncan(a)well-typed.com> * Fix name of template in user signup feature Ignore-this: 883829d860f59407c1a89a9dbf1b564a M ./Distribution/Server/Features/UserSignup.hs -1 +1 Mon Apr 8 22:14:51 BST 2013 Duncan Coutts <duncan(a)well-typed.com> * Do not offer http basic authentication Ignore-this: 47a9f1430c007f50f9a3549f24a29b04 We still accept it if the client offers it pre-emptively. M ./Distribution/Server/Framework/Auth.hs -10 +11

1 0

Cabal sandbox and rebuild of added sources
by Daniel Trstenjak 08 Apr '13

08 Apr '13

Hi, I just tried the sandbox functionality of cabal with the current version on github (b89d894947a9ec6fde78ebc6e7f6978f0b117eb1). If the source added by 'cabal sandbox-add-source' changes, than it gets rebuild by calling 'cabal sandbox-build', but not if I'm just calling 'cabal sandbox-install'. Is there a reason for this behavior? Greetings, Daniel

2 1

hackage trac
by Ian Lynagh 05 Apr '13

05 Apr '13

Hi all, A few IPs were hammering http://hackage.haskell.org/trac/hackage/wiki/HackageDB today which (is probably what) caused abbot to become inaccessible. /srv/trac/hackage/db/trac.db is 613MB, which seems rather suspicious: /srv/trac/ghc/db/trac.db is only 359MB. I wonder if it is full of spam? I'm also not able to load http://hackage.haskell.org/trac/hackage/wiki/HackageDB?action=history (it just times out). Could someone take a look please? Or perhaps the Cabal wiki should be moved elsewhere (github?) and the trac instance disabled? Thanks Ian

6 11

Re: Defining CH executables in cabal files
by Duncan Coutts 04 Apr '13

04 Apr '13

On Thu, 2013-04-04 at 15:46 +0100, Rob Stewart wrote: > Hi Duncan, Edsko. > > I'd like to know where I should most appropriately submit a bug > report, or indeed whether the behaviour that I am experiencing is a > bug or a user misuse of cabal. It's a consequence of a misunderstanding of how package names affect types and how different cabal constructs give you different package names. > I have packaged up a very simple send/receive example into a cabalised > archive. In there is a README that describes the problem succinctly, > though I will repeat here for convenience. It appears to be weirdness > with main-is and hs-source-dirs. In the .cabal file, there are three > executables of the same Receiver.hs file - a receiver of a CH message. > One appears to be defined in such a way that the CH primitives `match` > and `expect` are *not* receiving the message types that are being sent > by Sender.hs. The problem is that your three programs are using different types. ch-receiver-1 and ch-receiver-2 use the type cabal-with-ch-executables-1.0:Bar.Baz.Types.Msg while ch-receiver-3 uses the type Bar.Baz.Types.Msg Those are the fully-qualified names of those types and they are different, so they are different types, so have different Typeable fingerprints and so the `expect` does not match them. So as you can see, the fully qualified name of a type includes its package id, and in the first case it has the package name cabal-with-ch-executables-1.0 while in the second case it is the "home" package, which has no name (or if you like, it's called ""). Code in a library has fully qualified names that include the package name. Code in a top level executable is in the "home" package. The way you've constructed your three programs, the first two put the module in a library and the third puts it in the top level executable, so according to ghc it really is a different module. So lets look at your cabal file: > library > default-language: Haskell2010 > exposed-modules: Bar.Baz.Types > , Bar.Baz.Identify > build-depends: base >= 4 && < 5 > , binary >= 0.6.3.0 > , bytestring >= 0.9.2 > , distributed-process >= 0.4.2 > , network > , network-transport > , network-transport-tcp > hs-source-dirs: src > GHC-Options: -Wall > > -- Works > Executable ch-receiver-1 > default-language: Haskell2010 > main-is: Receiver.hs > build-depends: base > , distributed-process > , network-transport-tcp > , network-transport > , cabal-with-ch-executables > hs-source-dirs: examples > ghc-options: -Wall > > -- Works > Executable ch-receiver-2 > default-language: Haskell2010 > main-is: Receiver.hs > build-depends: base > , distributed-process > , network-transport-tcp > , network-transport > , cabal-with-ch-executables > hs-source-dirs: src/Bar/Baz > ghc-options: -Wall > > -- Doesn't work > Executable ch-receiver-3 > default-language: Haskell2010 > main-is: Bar/Baz/Receiver.hs > build-depends: base > , distributed-process > , network-transport-tcp > , network-transport > , cabal-with-ch-executables > > -- I don't understand why these below are now needed?? > , binary >= 0.6.3.0 > , bytestring >= 0.9.2 > , distributed-process >= 0.4.2 > , network > , network-transport > , network-transport-tcp > hs-source-dirs: src > ghc-options: -Wall So you have the first two executables depending on the library and they pick up their Bar.Baz.Types module from the library. Your third executable also depends on the library but the way you have the sources organised means that you're getting the modules from the source files and not from the library. This is because you're using the hs-source-dirs as src, which is where the modules for the library live. ghc will always pick local source files over modules from packages. This is also why you needed those extra dependencies, your executable is including those modules directly (you'll notice they're recompiled for the 3rd exe). The solution is that when you want to have an exe in a package depend on a lib in the same package, you need to separate the src dirs, as you did with the first one (hs-source-dirs: examples). Clear as mud? What would be good is if cabal would warn when the same module can be found both in a local lib that we depend on, and as a source file, because that's probably a mistake. It might also be good if we could tell ghc where to get the modules from explicitly, rather than rely on its behaviour about preferring src modules to package modules. Duncan

1 0