- cabal-devel - Haskell.org

Taking a step back
by Johan Tibell 20 Oct '15

20 Oct '15

Friends, I'm taking a step back from day-to-day library work. There are two main reasons I use Haskell: on one hand I find writing Haskell educational and fun. On the other I hope to make it a viable alternative to existing mainstream languages. With recent changes to our core libraries, and the general direction these are moving in, I believe we're moving away from becoming a viable alternative to those mainstream languages. This has some practical implications for how I spend my Haskell hacking time. Much of what I do is maintaining and working on libraries that are needed for real world usage, but that aren't that interesting to work on. I've lost the motivation to work on these. I've decided to take a step back from the core maintenance work on cabal, network, containers, and a few others* starting now. I've already found replacement maintainers for these. I still plan to hack on random side projects, including GHC, and to continue coming to Haskell events and conference, just with a shorter bug backlog to worry about. :) -- Johan Tibell * For now I will still hack on unordered-containers and ekg, as there are some things I'd like to experiment with there.

3 2

Cabal segfaults after update to GHC-7.10.2 from ports
by Eric McCorkle 20 Oct '15

20 Oct '15

Hello, I just updated my Haskell installation in FreeBSD 11 to GHC 7.10 using the ports tree. I am now seeing segfaults from cabal whenever I try to install anything, or even update the package list. Curiously, port builds of Haskell packages seem to work just fine, which leads me to believe the problem is in one of the dependencies as opposed to cabal itself. Also, I can manually compile and run simple programs. I tried various settings (LLVM/no, profile on/off, dynamic on/off) to no avail. Has anyone else seen this? Any advice on how to go about diagnosing the problem?

2 2

IRC logs for #hackage
by Danny Navarro 16 Oct '15

16 Oct '15

Since many interesting conversations related to cabal and hackage development happen in the #hackage channel, I wouldn't like to miss any of them. Keeping 1 day worth of logs would be fine with me. I was about to send a PR [1] to Chris' Done http://ircbrowse.net/, but I'd rather have explicit permission before doing so. I'm not sure who should I'm ask for though. [1]: https://github.com/jdnavarro/ircbrowse/commit/82657f77ea0d2158ae3fd92282d20… -- Danny Navarro | http://dannynavarro.net

3 3

HEAD-UPS: IRC presence for Haskell Infrastructure Hackathon 11-11th Oct 2015
by Herbert Valerio Riedel 10 Oct '15

10 Oct '15

Hi, as you may know, https://skillsmatter.com/conferences/7316-haskell-infrastructure-hackathon-… is starting right now! Attendees will be directed to the #hackage/freenode channel for task coordination, support, and counseling... It'd be great if those of you with some experience with the Cabal & Hackage code-base could join the #hackage channel today or tomorrow, and provide assistance. Moreover, there's a Wiki page for collecting task ideas up at https://github.com/haskell/cabal/wiki/Hackathon2015 if you have additional ideas, feel free to edit that page (if you lack permissions to edit, talk to us on #hackage) Cheers, hvr

1 0

Global Constraints for Cabal and also Release Plan?
by Gershom B 26 Sep '15

26 Sep '15

Any more feedback on this? And also, do we have any plans for an upcoming Cabal release? Braindump here: Once this lands and we have a cabal release, we can do a trial run of a new minimal platform release. So I'm inclined to try to target a cabal release for sooner than later if possible, to enable trying to get the "minimal platform" proposal happening. A "nice to have" in the future for the platform would be to help address https://github.com/haskell/haskell-platform/issues/207 The proposal there would be to add an env variable (perhaps CABAL_PATH_PREFIX) which, if it existed, would be added to the path before running child processes (such as those kicked off by build-type:configure). That way windows environments could provide the Msys2 bin directory and those tools would then be made available to the configure scripts, etc. I haven't investigated adding this yet, but I don't think it would be too much work. If people are open to this, and especially if there were some pointers, I'd be happy to look at this. In any case, this is only a "nice to have" since it can be worked around with an explicit "switcher script" prior to running cabal-install. Anyway, what are people's thoughts on A) getting the "global constraints" PR added (https://github.com/haskell/cabal/pull/2820) B) possibly adding the cabal-path-prefix logic, and C) a release timetable with or without B so as to enable facilitate a minimal platform release? -g On Fri, Sep 11, 2015 at 5:17 PM, Gershom B <gershomb(a)gmail.com> wrote: > I've changed Freeze.hs to also respect this flag, and submitted a pull request: > > https://github.com/haskell/cabal/pull/2820 > > --Gershom > > On Thu, Sep 10, 2015 at 6:45 PM, Gershom B <gershomb(a)gmail.com> wrote: >> Hi all. I've got a branch of cabal with a new feature: >> https://github.com/gbaz/cabal/tree/constraints-config >> >> This lets you either pass `constraints-file` on the command line or in >> the ~/.cabal/config file. >> >> The constraints-file serves as a "default" cabal.config file for >> freezes should one not be provided by a particular package. >> >> Thus, a "minimal" platform can ship with a file that includes the >> platform constraints. Later, a user can simply download a new file for >> a new constraints set -- say lts -- and swap their config to point to >> that instead. >> >> This makes both the platform in its new ideally-more-minimal guise and >> stackage play nicer together and with cabal, in a way that required >> minimal changes to cabal proper. >> >> Ideally this or a relative can land soon to help enable the minimal >> platform plans (the work grew out of the discussion on: >> https://github.com/haskell/haskell-platform/issues/206) >> >> There are two places where I wasn't quite sure what to do. In >> PackageEnvironment.hs, the tryLoadSandboxPackageEnvironmentFile >> doesn't check if this flag is set and handle that case. So this is >> when we are already in a sandbox and the question is if we should >> _also_ respect this flag, just as a sandbox also respects a >> cabal.config file directly in the directory. My gut says "don't >> respect it in sandboxes" but i'm not sure. >> >> Additionally, the freezePackages function in Freeze.hs doesn't respect >> this flag. I'm not sure exactly what the full call chain here is yet, >> so haven't worked out the logic. >> >> Anyway, thoughts? >> >> --gershom

3 9

PR action-required tag, and a Phabricator instance
by Edward Z. Yang 24 Sep '15

24 Sep '15

Hey all, Two quick reports for Cabal: 1. I've tagged all PRs as either cabal-install/library. This should help triage, since the nature of patches to these different projects can be quite different. 2. I've tagged PRs that are KNOWN to not be mergeable (either due to Travis failure or something pending that needs to be fixed as) action-required. PRs that do NOT have this tag are untriaged. Please look at them and decide if we can merge them or reject them. 3. thoughtpolice set us up a callsign on phabricator.haskell.org and I added an .arcconfig so we can accept "arc diff"s now too. I've added Cabal people with Phabricator accounts to it https://phabricator.haskell.org/tag/cabal/ If I missed you let me (or someone else who is a member) know. Don't forget to sign up to hear notifications about any portions of code you might care about. Edward

1 0

Renaming InstalledPackageId
by Edward Z. Yang 18 Sep '15

18 Sep '15

Hello friends, During discussions with many people about Nix-like Cabal, it has emerged that InstalledPackageId is /really/ bad name. Consider: the commonly accepted definition of an InstalledPackageId in Nix is that it is morally a hash of all the inputs to compilation: the source code, the dependencies of the package, and the build configuration. However, a Cabal package can have *multiple* components (e.g. the library, the test suite, etc), each of which has its own 'build-depends' field. The concept of the "dependencies of a package" is simply not well-defined! The "simplification" that Cabal has adopted for a long time is to say that the installed package ID always refers to the library component of a package. [1] But the name InstalledPackageId has caused countless misunderstandings about how dependency resolution is done, even in Cabal's code. [2] I propose that we change the name of InstalledPackageId. The new name should have the following properties: 1. It should not say anything about packages, because it is not well-defined for a package, e.g. it should be something like "ComponentId". 2. It should not say anything about installation, because it is well-defined even before a package is even built. 3. It should some how communicate that it is a hash of the transitive source code (e.g. including dependencies) as well as build parameters. SPJ likes "SourceHash" because it's evocative of this (though I don't like it as much); there may also be a Nix-y term like "Derivation" we can use here. My proposed new name is "ComponentBuildHash", however I am open to other suggestions. I might also be convinced by "InstalledComponentId" (which runs aground (2) but is fairly similar to the old name, and gains points for familiarity.) However, I would like to hear your comments: have a better name? Think this is unnecessary? Please let me know. Edward P.S. With Backpack, the ComponentBuildHash won't even be the primary key into the installed package (to be renamed to a component/unit) database, because a single ComponentBuildHash can be rebuilt multiple times with different instantiations of its holes. So GHC will have some identifier, which we will probably continue to call the 'UnitKey', which is the ComponentBuildHash (entirely Cabal generated) plus extra information about how holes are instantiated (entirely GHC generated). [1] Except when it doesn't: cabal-install currently merges all the dependencies of all components that are being built for a package together and treats that as the sum total dependencies of the package. This causes problems when the test suite for text depends on a testing library which in turn depends on text, c.f. https://github.com/haskell/cabal/issues/960 [2] Here are some bugs caused by confusion of package dependencies versus component dependency: https://github.com/haskell/cabal/issues/2802 Specify components when configuring, not building https://github.com/haskell/cabal/issues/2623 `-j` should build package components in parallel https://github.com/haskell/cabal/issues/1893 Use per-component cabal_macros.h https://github.com/haskell/cabal/issues/1575 Do dependency resolution on a per component basis https://github.com/haskell/cabal/issues/1768 The "benchmark" target dependencies conflict with "executable" targets https://github.com/haskell/cabal/issues/960 Can't build with --enable-tests in presence of circular dependencies

2 1

Global Constraints for Cabal
by Gershom B 11 Sep '15

11 Sep '15

Hi all. I've got a branch of cabal with a new feature: https://github.com/gbaz/cabal/tree/constraints-config This lets you either pass `constraints-file` on the command line or in the ~/.cabal/config file. The constraints-file serves as a "default" cabal.config file for freezes should one not be provided by a particular package. Thus, a "minimal" platform can ship with a file that includes the platform constraints. Later, a user can simply download a new file for a new constraints set -- say lts -- and swap their config to point to that instead. This makes both the platform in its new ideally-more-minimal guise and stackage play nicer together and with cabal, in a way that required minimal changes to cabal proper. Ideally this or a relative can land soon to help enable the minimal platform plans (the work grew out of the discussion on: https://github.com/haskell/haskell-platform/issues/206) There are two places where I wasn't quite sure what to do. In PackageEnvironment.hs, the tryLoadSandboxPackageEnvironmentFile doesn't check if this flag is set and handle that case. So this is when we are already in a sandbox and the question is if we should _also_ respect this flag, just as a sandbox also respects a cabal.config file directly in the directory. My gut says "don't respect it in sandboxes" but i'm not sure. Additionally, the freezePackages function in Freeze.hs doesn't respect this flag. I'm not sure exactly what the full call chain here is yet, so haven't worked out the logic. Anyway, thoughts? --gershom

1 1

cabal-install rebooted?
by Bardur Arantsson 09 Sep '15

09 Sep '15

Hi all, So, I was feeling a bit frustrated about the complexity of the Cabal sandbox code, and when I get frustrated I start deleting things... Just for funzies I tried deleting all the obvious non-sandbox code in cabal-install, and here's the result: https://github.com/BardurArantsson/cabal/commit/27aa116cc0ab3c824bd80c175ec… As you can see it means the removal of 218 lines, but most importantly IMO it drastically simplifies the code in some places, notably loadConfigOrSandboxConfig (funnily enough) becomes trivial and classifyPackageEnvironment disappears (conincidence? I think not.). I'm sure there are quite a few other things that could also be removed. I've left a few notes sprinkled in the code marked by XXX. Obviously, this isn't mergeable as-is[1] and I mostly did it for a lark, but what do you guys think? Is this something that could/should be pursued further? I seem to recall hearing some rumblings that some people really wanted cabal-install to be sandbox-only. I think this little Proof of Concept shows that it would be beneficial at least from a code complexity/maintenance perspective. (I certainly know that I've been getting really frustrated trying to implement #2810 because the code is incredibly *gnarly* because it has to account for a lot of combinations of things, and this might be a good way to try to reverse the tide of option-itis.) Regards, /b [1] For one thing, there's need to be some sort of deprecation period of non-sandbox mode at the very least. :)

3 4

Issue #2810: Search upwards for package directory
by Bardur Arantsson 05 Sep '15

05 Sep '15

Hey all, I've been working a bit on #2810 and would love to have initial review comments; see https://github.com/haskell/cabal/issues/2810 https://github.com/haskell/cabal/issues/2811 (pull req) (Btw, would it be possible to assign me to the issue?) I'd especially like comments on the following: - Does this look like a sane approach? - Are the any obvious-to-cabal-experts problems here? - I'd especially like feedback on the non-trivial FIXMEs. (There are some really obvious things I just haven't got round to.) Regards,

1 3