September 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

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