June 2015 - cabal-devel

ANN: cabal-install-1.22.6.0 has been released
by Ryan Thomas 27 Jan '16

27 Jan '16

Hi all, A new minor release of cabal-install has been released, this is to pick up a fix for @ezyang's fix for #2502. This is now available on hackage and the downloads page and the sha1sum is listed below. Cheers, ryan d474b0eef6944af1abef92419cea13cee50993f3 cabal-install-1.22.6.0.tar.gz

3 5

Cabal and simultaneous installations of the same package
by Simon Peyton Jones 29 Aug '15

29 Aug '15

Dear Cabal developers You'll probably have seen the thread about the Haskell Platform. Among other things, this point arose: | Another thing we should fix is the (now false) impression that HP gets in | the way of installing other packages and versions due to cabal hell. People mean different things by "cabal hell", but the inability to simultaneously install multiple versions of the same package, compiled against different dependencies is certainly one of them, and I think it is the one that Yitzchak is referring to here. But some time now GHC has allowed multiple versions of the same package (compiled against different dependencies) to be installed simultaneously. So all we need to do is to fix Cabal to allow it too, and thereby kill of a huge class of cabal-hell problems at one blow. But time has passed and it hasn't happened. Is this because I'm misunderstanding? Or because it is harder than I think? Or because there are much bigger problems? Or because there is insufficient effort available? Or what? Unless I'm way off beam, this "multiple installations of the same package" thing has been a huge pain forever, and the solution is within our grasp. What's stopping us grasping it? Simon

8 17

Issues, issues, issues...
by Bardur Arantsson 28 Jun '15

28 Jun '15

Hi all, (When I refer to cabal below, I'm mainly referring to cabal-install.) As some of the project owners have probably noticed (hi, sorry about the ticket spam!), I've been sampling a few issues from the issue tracker here and there to look into the potential issues I could tackle and which would make sense to actually implement. A few observations: - The issues imported from the old tracker are almost completely useless. A huge number of them are "enhancement" level and there's usually there not even any way to get in contact with the original reporter since it's just Trac usernames. Since Bryan O'Sullivan did the original import his username "bos" is the "reporter" for all the imported issues. - The issues in the _|_ milestone seem to suffer from largely the same problems. I'm sure there's some overlap between this and the previous issue list. I would suggest that *all* "enhancement" level issues from the above lists which have lain dormant for >1 year (or so) be closed. After that amount of time, it's obviously not going to happen. On a similar note, I've stumbled on quite a lot of issues which seem to arise from people wantonly manipulating sandboxes directly, (ab)using symlinks, and/or expecting to be able to build (or whatever) in the same sandbox in parallel, and issues of a similar nature. From various comments in tracker by @tibbe, I gather that the idea is to do away with the need for a lot of the direct sandbox manipulation that (esp. multi-package) developers need to do to get their setups working. Therefore I would suggest aggressively closing as many of these tickes as is feasible as "wontfix", even if they may technically be bugs. (Of course it depends on the priority of the bug, but...). I can probably spend a few hours today to scour through the bug list and find + "report" (via comment) bugs of this nature if there's interest in that. In general: The issue tracker is in an atrocious state and it's almost impossible for a noob like me to find anything even remotely relevant that's a) relevant to work on from a "this is the direction we want to be going" perspective, and b) is interesting from the "has any potential users" perspecitve[1]. I'm sure this has a lot to do with the overall uselessness of GitHub's issue tracker for anything above 20 issues and the fact that going through bugs is probably boring as hell for most people. Therefore I'd also suggest instituting a general guideline that *all* issues with no discernible activity for >1 year (or so) be aggresively closed. If nothing has happened in that time we're not talking about anything that's (realistically) going to happen given that nobody(?) is actually working on Cabal/cabal-install full-time. I guess a comment to the effect of "If you still care about this please re-open" to the original poster would be manageable. In any case, the default must be to close -- not to just keep issues open just-in-case they're still relevant. As it currently stands the tracker is unfortunately all but useless. In fact, it's actively discouraging because it's so daunting :( Sorry about the bile, but it has to be said because I think it's terribly discouraging for potential contributors and could be causing a massive waste of time fixing/implementing things which are irrelevant for FutureCabalInstall. I should stress that I don't mean any of this as any kind of negativity towards the project owners/maintainers themselves (it's a thankless job!) -- it just needs to be said. As mentioned, I'll be happy to help out a bit with the weeding-out of issues, but unless we can agree to some of the above then I'm not going to waste my time. Regards, P.S. There seems to be a bit of a pull request backlog too. (I'm *not* talking about my own PRs here!) There seem to be 5-6 pull requests that have lingered since 2014(!). IMO they should either be merged or rejected (back into issue tracker if necessary). It doesn't serve anyone to have pull requests linger for a year. [1] A lot of the issues seem to be extremely niche feature requests, many revolving around needs which users with homemade scripting (or cabal-dev, henv, or what have you) have had at one time or another.

5 11

Multi-library/package support for cabal
by Bardur Arantsson 24 Jun '15

24 Jun '15

Hi all, Given that I'm often quite annoyed by the almost-total lack of support for developing a set of coherent libraries together in a convenient fashion[1] using Cabal, I'd like to ask a) are there any current plans or GitHub issues on implementing any support for this workflow that I should be aware of? b) are there any wiki pages (or similar) detailing any requirements that people might have for this type of workflow? c) would there be *interest* in somebody (e.g. me) implementing support for such a workflow? d) if "yes" to c), how should one go about it? What kind of consensus needs to gathered and whom do I need to convince of the brilliance of this idea? I should note that I have *very* little experience with Cabal/cabal-install's code (a couple of pretty trivial patches, I think), but it's Haskell, so how bad could it be, right? I have a week's vacation coming up next week (and probably a few more a little later in the summer), and I think I may be able to dedicate quite a bit of time to getting this done, *but*... if I'm going to spend that time, I want something that can be integrated into cabal-install *and* I want something that has a reasonable chance of actually getting merged. (Of course, I don't expect bad code to be merged, but I'm quite happy to fix bad code whenever it's pointed out to me.) Otherwise, I'll just keep using cobbled-together one-off Python scripts (and terribly inefficient workflows)... and complaining constantly about it :). So... how can get this ball rolling? Regards, [1] E.g. I have a set of cqrs-* libraries + demo executable packages in a single git repository, each with their own subdirectory and .cabal file. These libraries may depend on each other in arbitrary non-circular ways and I want to be able to conveniently build all of it in the appropriate order and with a consistent set of dependencies in a single sandbox.

3 4

ANN: Cabal and cabal-install 1.22 minor releases
by Ryan Thomas 17 Jun '15

17 Jun '15

Hi all, A release of Cabal has been made in order to get some fixes into GHC 7.10.2. This is version 1.22.4.0, a corresponding version of cabal-install (1.22.5.0) has also been released. The changelogs for these releases are below: Cabal: 1.22.4.0 Ryan Thomas <ryan(a)ryant.org> June 2015 * Add libname install-dirs variable, use it by default. Fixes #2437. (Edward Z. Yang) * Reduce temporary directory name length, fixes #2502. (Edward Z. Yang) * Workaround for #2527. (Mikhail Glushenkov) cabal-install: 1.22.5.0 Ryan Thomas <ryan(a)ryant.org> June 2015 * Reduce temporary directory name length, fixes #2502. (Edward Z. Yang) These are now available on the dowloads page and on Hackage. The checksums are listed below. Cheers, ryan da3c6977749ed5ea1422d58e8aed7265d57f7280 Cabal-1.22.4.0.tar.gz dbe6af3d3bd99e8e34392d28fe8d9e97e697757c cabal-install-1.22.5.0.tar.gz

1 0

Re: HEADS UP: Final call for 7.10.2 is soon
by Johan Tibell 09 Jun '15

09 Jun '15

There have been some requests for a Cabal library release for 7.10.2. I remember something about truncate directories/symbol names being an issue. I'm CC:ing the Cabal mailing list for comments. On Wed, Jun 3, 2015 at 3:40 PM, Sergei Meshveliani <mechvel(a)botik.ru> wrote: > Please, > consider my recent bug report > "overlapping instances in 7.10.1" > (see my resent email to this list). > > ------ > Sergei > > > > On Tue, 2015-06-02 at 16:31 -0500, Austin Seipp wrote: > > Hi *, > > > > I've just finished merging all the latest patches for GHC 7.10.2 into > > the STABLE branch. All in all, we've fixed a lot of bugs (over 80 > > tickets closed)! > > > > So, we'll probably be doing a 7.10.2 release here in a few weeks. The > > tentative plan was around the 14th, although it's not set in stone. > > (At worst, it would be pushed from the 14th to the 21st). > > > > With that in mind, if I could quickly direct your attention to the GHC > > bug tracker and the status page[1] - it would be really helpful if you > > check if the things you want are fixed! > > > > Specifically, if you want something fixed for the 7.10.2 release: > > > > - Make sure there is a ticket. It really needs to exist or we'll just > forget! > > > > - If your bug is critical, please explain why! We really want to > > kill showstoppers ASAP, because bugs are much cheaper to fix early. If > > that's the case we can bump the priority if it's necessary to make > > things clear. > > > > - Set the milestone to 7.10.2. It'll automatically appear on the > status page. > > > > That should be it - we'll be monitoring the status page regularly to > > keep track of new things. The current bug list is pretty small - we > > may move some of them out, or fix several more. So just try to let us > > know. > > > > As a sidenote, I'm quite happy with this release - it's fixed dozens > > of tricky bugs, improved some nasty corner cases in compiler > > performance, and overall seems like it will be high quality. Thanks to > > everyone who submitted patches! > > > > I'll send out another email next week as another reminder. > > > > [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.2 > > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >

2 1