From spam at scientician.net Fri Sep 4 18:23:24 2015 From: spam at scientician.net (Bardur Arantsson) Date: Fri, 4 Sep 2015 20:23:24 +0200 Subject: Issue #2810: Search upwards for package directory Message-ID: 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, From spam at scientician.net Fri Sep 4 18:28:15 2015 From: spam at scientician.net (Bardur Arantsson) Date: Fri, 4 Sep 2015 20:28:15 +0200 Subject: Issue #2810: Search upwards for package directory In-Reply-To: References: Message-ID: On 09/04/2015 08:23 PM, Bardur Arantsson wrote: > Hey all, > > - I'd especially like feedback on the non-trivial FIXMEs. > (There are some really obvious things I just haven't got > round to.) Btw, I'll try to address the obvious FIXMEs tomorrow just to make review a bit easier. Regards, From spam at scientician.net Sat Sep 5 07:48:26 2015 From: spam at scientician.net (Bardur Arantsson) Date: Sat, 5 Sep 2015 09:48:26 +0200 Subject: Issue #2810: Search upwards for package directory In-Reply-To: References: Message-ID: On 09/04/2015 08:23 PM, Bardur Arantsson wrote: > Hey all, > [--snip--] And interesting issue came up during discussion that I'd like to bring up here too, just in case people have muted their github mail[1], namely the handling of CWD -- it's fixable, but the simplest and most robust fix I can think of is going towards a git-like model of subcommand handling; see https://github.com/haskell/cabal/issues/2349#issuecomment-137925036 (I just wanted to bring to the attention of people on the list who may not be following along.) Cheers, [1] I think I've now grown a certain sympathy for people who say that GitHub's issue tracker is truly awful for a project of this (or any non-trivial) size which doesn't have a full-time team following up on issues. Anyone want to change bug trackers? ;) From spam at scientician.net Sat Sep 5 08:20:12 2015 From: spam at scientician.net (Bardur Arantsson) Date: Sat, 5 Sep 2015 10:20:12 +0200 Subject: Issue #2810: Search upwards for package directory In-Reply-To: References: Message-ID: On 09/05/2015 09:48 AM, Bardur Arantsson wrote: > On 09/04/2015 08:23 PM, Bardur Arantsson wrote: >> Hey all, >> > [--snip--] > Nvm, I'm a dork. Sorry about the spam. From spam at scientician.net Tue Sep 8 17:16:37 2015 From: spam at scientician.net (Bardur Arantsson) Date: Tue, 8 Sep 2015 19:16:37 +0200 Subject: cabal-install rebooted? Message-ID: 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/27aa116cc0ab3c824bd80c175ecbe51955dd9271 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. :) From gershomb at gmail.com Tue Sep 8 22:22:38 2015 From: gershomb at gmail.com (Gershom B) Date: Tue, 8 Sep 2015 18:22:38 -0400 Subject: cabal-install rebooted? In-Reply-To: References: Message-ID: That _does_ look simpler! However, I think there are multiple efforts underway towards the nix-style stuff. We had a GSoC on that for example. And in that workflow, if it all works out properly, then we end up with a situation where since the general-user-db has no conflicts, then sandboxes are the tools that become generally not required. So I would be quite hesitant about moving things in the other direction... -g On Tue, Sep 8, 2015 at 1:16 PM, Bardur Arantsson wrote: > 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/27aa116cc0ab3c824bd80c175ecbe51955dd9271 > > 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. :) > > _______________________________________________ > cabal-devel mailing list > cabal-devel at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel From spam at scientician.net Wed Sep 9 04:37:20 2015 From: spam at scientician.net (Bardur Arantsson) Date: Wed, 9 Sep 2015 06:37:20 +0200 Subject: cabal-install rebooted? In-Reply-To: References: Message-ID: On 09/09/2015 12:22 AM, Gershom B wrote: > That _does_ look simpler! > > However, I think there are multiple efforts underway towards the > nix-style stuff. We had a GSoC on that for example. And in that > workflow, if it all works out properly, then we end up with a > situation where since the general-user-db has no conflicts, then > sandboxes are the tools that become generally not required. > > So I would be quite hesitant about moving things in the other direction... > I do see some advantages to having sandboxes still, namely isolation of the binaries into a single directory that you can put into $PATH, but I'm assuming/hoping there's some way to handle that in nix-style cabal/cabal-install as well. (If that turns out to be wrong, I imagine a middle-of-the-road approach here would be to just have a single package database and treat it as a simple cache of all the binaries ever compiled and we could still keep sandboxing for binaries and such..That might also nicely solve the problem of redudant compilation which happens with sandboxes now.) Just out of curiousity, when is the GSoC deadline? FWIW, I'd also be happy if sandboxes could be scrapped (as being unnecessary) rather than the other way round. The main point of this execercise was to show how much simpler things *could* be, if we really want them to. (I think cabal-install *needs* to become a lot simpler if it's to be in any way maintainable and extendable.) Regards, From _deepfire at feelingofgreen.ru Wed Sep 9 08:08:09 2015 From: _deepfire at feelingofgreen.ru (Kosyrev Serge) Date: Wed, 09 Sep 2015 11:08:09 +0300 Subject: cabal-install rebooted? In-Reply-To: (sfid-20150909_085904_718627_06D0C0D1) (Bardur Arantsson's message of "Wed, 9 Sep 2015 06:37:20 +0200") References: Message-ID: <87k2s0j9qu.fsf@andromedae.feelingofgreen.ru> Bardur Arantsson writes: > On 09/09/2015 12:22 AM, Gershom B wrote: >> That _does_ look simpler! >> >> However, I think there are multiple efforts underway towards the >> nix-style stuff. We had a GSoC on that for example. And in that >> workflow, if it all works out properly, then we end up with a >> situation where since the general-user-db has no conflicts, then >> sandboxes are the tools that become generally not required. >> >> So I would be quite hesitant about moving things in the other direction... >> > > I do see some advantages to having sandboxes still, namely isolation of > the binaries into a single directory that you can put into $PATH, but > I'm assuming/hoping there's some way to handle that in nix-style > cabal/cabal-install as well. (If that turns out to be wrong, I imagine a > middle-of-the-road approach here would be to just have a single package > database and treat it as a simple cache of all the binaries ever > compiled and we could still keep sandboxing for binaries and such..That > might also nicely solve the problem of redudant compilation which > happens with sandboxes now.) > > Just out of curiousity, when is the GSoC deadline? Success was recently announced: https://www.mail-archive.com/cabal-devel%40haskell.org/msg10091.html Excerpts: ,---- | Cabal should never tell you it can't install a package because some | reinstalls would be necessary. `---- ,---- | Try building things without a sandbox and see what happens! | (When I test, I've tried installing multiple version of Yesod | at the same time.) `---- -- ? ???????e? / respectfully, ??????? ?????? -- ?And those who were seen dancing were thought to be insane by those who could not hear the music.? ? Friedrich Wilhelm Nietzsche From spam at scientician.net Wed Sep 9 15:54:15 2015 From: spam at scientician.net (Bardur Arantsson) Date: Wed, 9 Sep 2015 17:54:15 +0200 Subject: cabal-install rebooted? In-Reply-To: <87k2s0j9qu.fsf@andromedae.feelingofgreen.ru> References: <87k2s0j9qu.fsf@andromedae.feelingofgreen.ru> Message-ID: On 09/09/2015 10:08 AM, Kosyrev Serge wrote: > Bardur Arantsson writes: > >> On 09/09/2015 12:22 AM, Gershom B wrote: >>> That _does_ look simpler! >>> >>> However, I think there are multiple efforts underway towards the >>> nix-style stuff. We had a GSoC on that for example. And in that >>> workflow, if it all works out properly, then we end up with a >>> situation where since the general-user-db has no conflicts, then >>> sandboxes are the tools that become generally not required. >>> >>> So I would be quite hesitant about moving things in the other direction... >>> >> >> I do see some advantages to having sandboxes still, namely isolation of >> the binaries into a single directory that you can put into $PATH, but >> I'm assuming/hoping there's some way to handle that in nix-style >> cabal/cabal-install as well. (If that turns out to be wrong, I imagine a >> middle-of-the-road approach here would be to just have a single package >> database and treat it as a simple cache of all the binaries ever >> compiled and we could still keep sandboxing for binaries and such..That >> might also nicely solve the problem of redudant compilation which >> happens with sandboxes now.) >> >> Just out of curiousity, when is the GSoC deadline? > > Success was recently announced: > > https://www.mail-archive.com/cabal-devel%40haskell.org/msg10091.html > Thanks for the pointer. Not sure how I missed that. Looks very promising -- I'll give it a whirl some time in the next few days. Regards, From gershomb at gmail.com Thu Sep 10 22:45:20 2015 From: gershomb at gmail.com (Gershom B) Date: Thu, 10 Sep 2015 18:45:20 -0400 Subject: Global Constraints for Cabal Message-ID: 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 From gershomb at gmail.com Fri Sep 11 21:17:48 2015 From: gershomb at gmail.com (Gershom B) Date: Fri, 11 Sep 2015 17:17:48 -0400 Subject: Global Constraints for Cabal In-Reply-To: References: Message-ID: 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 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 From ezyang at mit.edu Fri Sep 18 03:33:23 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Thu, 17 Sep 2015 20:33:23 -0700 Subject: Renaming InstalledPackageId Message-ID: <1442545148-sup-5662@sabre> 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 From simonpj at microsoft.com Fri Sep 18 09:22:12 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 18 Sep 2015 09:22:12 +0000 Subject: Renaming InstalledPackageId In-Reply-To: <1442545148-sup-5662@sabre> References: <1442545148-sup-5662@sabre> Message-ID: <2485471570b745b0aa294804f9f5fae6@DB4PR30MB030.064d.mgd.msft.net> Good idea! | suggestions. I might also be convinced by "InstalledComponentId" (which I dislike the "installed" part for the reasons you say. And I would really love to have some indication that this is a hash or MD5 sum of the entire INPUT to the compilation process (source code, flags...). That's why I liked ComponentSourceHash; the "source" stresses input; the "hash" connotes the idea of summarising all the source code transitively. Simon | -----Original Message----- | From: cabal-devel [mailto:cabal-devel-bounces at haskell.org] On Behalf Of | Edward Z. Yang | Sent: 18 September 2015 04:33 | To: cabal-devel; ghc-devs | Subject: Renaming InstalledPackageId | | 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://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.co | m%2fhaskell%2fcabal%2fissues%2f960&data=01%7c01%7csimonpj%40064d.mgd.micro | soft.com%7cee169cf81c354b8200d008d2bfd9ec59%7c72f988bf86f141af91ab2d7cd011 | db47%7c1&sdata=3sQjxpWQccNyIR43FYonKTAQ3ENahciXLKtauzLKyXk%3d | | [2] Here are some bugs caused by confusion of package dependencies | versus component dependency: | https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.co | m%2fhaskell%2fcabal%2fissues%2f2802&data=01%7c01%7csimonpj%40064d.mgd.micr | osoft.com%7cee169cf81c354b8200d008d2bfd9ec59%7c72f988bf86f141af91ab2d7cd01 | 1db47%7c1&sdata=hcGUnJdwYz9GkKILhc8u9qgQrxTkcGUAqpd6VgW7k5I%3d Specify | components when configuring, not building | https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.co | m%2fhaskell%2fcabal%2fissues%2f2623&data=01%7c01%7csimonpj%40064d.mgd.micr | osoft.com%7cee169cf81c354b8200d008d2bfd9ec59%7c72f988bf86f141af91ab2d7cd01 | 1db47%7c1&sdata=QcllkUWL%2bTakINFCnty%2f30UsFDtb6y4NaNHa72Sy28Y%3d `-j` | should build package components in parallel | https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.co | m%2fhaskell%2fcabal%2fissues%2f1893&data=01%7c01%7csimonpj%40064d.mgd.micr | osoft.com%7cee169cf81c354b8200d008d2bfd9ec59%7c72f988bf86f141af91ab2d7cd01 | 1db47%7c1&sdata=NnRigIN%2fI%2fVrFgpjhZr7TaavIIdom1JBldlw4wlvpyA%3d Use | per-component cabal_macros.h | https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.co | m%2fhaskell%2fcabal%2fissues%2f1575&data=01%7c01%7csimonpj%40064d.mgd.micr | osoft.com%7cee169cf81c354b8200d008d2bfd9ec59%7c72f988bf86f141af91ab2d7cd01 | 1db47%7c1&sdata=xakCm5et0uCGy9TxCoL5GfosGQfGdytzFXGX92Tqe3o%3d Do | dependency resolution on a per component basis | https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.co | m%2fhaskell%2fcabal%2fissues%2f1768&data=01%7c01%7csimonpj%40064d.mgd.micr | osoft.com%7cee169cf81c354b8200d008d2bfd9ec59%7c72f988bf86f141af91ab2d7cd01 | 1db47%7c1&sdata=GCMmO3OZbl9RXswxeVd2d5%2bTu9eQ7DqhNyqwePvg9x0%3d The | "benchmark" target dependencies conflict with "executable" targets | https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.co | m%2fhaskell%2fcabal%2fissues%2f960&data=01%7c01%7csimonpj%40064d.mgd.micro | soft.com%7cee169cf81c354b8200d008d2bfd9ec59%7c72f988bf86f141af91ab2d7cd011 | db47%7c1&sdata=3sQjxpWQccNyIR43FYonKTAQ3ENahciXLKtauzLKyXk%3d Can't build | with --enable-tests in presence of circular dependencies | _______________________________________________ | cabal-devel mailing list | cabal-devel at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haske | ll.org%2fcgi-bin%2fmailman%2flistinfo%2fcabal- | devel&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cee169cf81c354b8200 | d008d2bfd9ec59%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=0k73G6r0wXJ5qA | HcrbUqpUjKaWvLuEXR%2fQAwF2XwH6c%3d From gershomb at gmail.com Mon Sep 21 22:11:37 2015 From: gershomb at gmail.com (Gershom B) Date: Mon, 21 Sep 2015 18:11:37 -0400 Subject: Global Constraints for Cabal and also Release Plan? Message-ID: 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 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 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 From ezyang at mit.edu Thu Sep 24 07:46:04 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Thu, 24 Sep 2015 00:46:04 -0700 Subject: PR action-required tag, and a Phabricator instance Message-ID: <1443080245-sup-2442@sabre> 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 From spam at scientician.net Thu Sep 24 15:01:26 2015 From: spam at scientician.net (Bardur Arantsson) Date: Thu, 24 Sep 2015 17:01:26 +0200 Subject: Global Constraints for Cabal and also Release Plan? In-Reply-To: References: Message-ID: On 09/22/2015 12:11 AM, Gershom B wrote: [--snip--] > > 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'm not sure I understand... what does CABAL_PATH_PREFIX add over just adding whatever is needed to the $PATH before executing cabal? (Without having looked at the issue thread.) I'm mainly worried about option-itis... which cabal-install is already suffering a lot from. Regards, From gershomb at gmail.com Thu Sep 24 15:06:51 2015 From: gershomb at gmail.com (Gershom B) Date: Thu, 24 Sep 2015 11:06:51 -0400 Subject: Global Constraints for Cabal and also Release Plan? In-Reply-To: References: Message-ID: On September 24, 2015 at 11:01:53 AM, Bardur Arantsson (spam at scientician.net) wrote: > On 09/22/2015 12:11 AM, Gershom B wrote: > [--snip--] > > > > 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'm not sure I understand... what does CABAL_PATH_PREFIX add over just > adding whatever is needed to the $PATH before executing cabal? > > (Without having looked at the issue thread.) > > I'm mainly worried about option-itis... which cabal-install is already > suffering a lot from. This is a fine question. By the way, I realized this might better be served as a cabal-path-prefix option (in cabal config) rather than an env variable, since that is more uniform. In any case, the issue is this. Suppose I want to work with MSys2, as MinGHC does. This is what lets me build against various c libraries, even in a windows environment. To do so, I need all the MSys2 tools in my path. So far, so good. But? those tools overlap in name with other tools in my path. For example, with my existing cygwin installation. And also with other tools of the same names at times that are the _windows_ versions of those common utilities. So, I want MSys2 tools in my path but _only_ when I am building cabal packages, and not otherwise. Either I manually modify my env each time I want to build a cabal package, _or_ we teach cabal to be clever and handle it for us, which is the motivation for this. Certainly, if we want a good ?out of the box? experience for windows users, asking them to modify their path before they run cabal, every time they do so, is not a very great experience. ?gershom From the.dead.shall.rise at gmail.com Thu Sep 24 15:52:48 2015 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Thu, 24 Sep 2015 17:52:48 +0200 Subject: Global Constraints for Cabal and also Release Plan? In-Reply-To: References: Message-ID: On 24 September 2015 at 17:06, Gershom B wrote: > So, I want MSys2 tools in my path but _only_ when I am building cabal packages, and not otherwise. IIUC, 'extra-prog-path' in '~/.cabal/config' already does what you want. It looks like it also supports multiple directories, using comma as separator. From gershomb at gmail.com Thu Sep 24 15:56:27 2015 From: gershomb at gmail.com (Gershom B) Date: Thu, 24 Sep 2015 11:56:27 -0400 Subject: Global Constraints for Cabal and also Release Plan? In-Reply-To: References: Message-ID: On September 24, 2015 at 11:52:51 AM, Mikhail Glushenkov (the.dead.shall.rise at gmail.com) wrote: > On 24 September 2015 at 17:06, Gershom B wrote: > > So, I want MSys2 tools in my path but _only_ when I am building cabal packages, and not > otherwise. > > IIUC, 'extra-prog-path' in '~/.cabal/config' already does what you > want. It looks like it also supports multiple directories, using comma > as separator. Hmm? we should investigate if that is sufficient, or if it can be changed to do so. Consider for example if we have a configure build-type, that runs an autoconf script. It is not enough that the executable we run be in the path, but also that the ?path? available to the autoconf script be amended as well. So if this only changes where _cabal_ searches for executables, but does not affect the path made available to them, I think this will be insufficient? The potential overlap is certainly worth investigating, though. -g From the.dead.shall.rise at gmail.com Thu Sep 24 16:16:29 2015 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Thu, 24 Sep 2015 18:16:29 +0200 Subject: Global Constraints for Cabal and also Release Plan? In-Reply-To: References: Message-ID: On 24 September 2015 at 17:56, Gershom B wrote: > Consider for example if we have a configure build-type, that runs an autoconf script. It is not enough that the executable we run be in the path, but also that the ?path? available to the autoconf script be amended as well. Yes, 'extra-prog-path' also affects the PATH environment variable of the programs invoked by cabal-install: https://github.com/haskell/cabal/blob/master/Cabal/Distribution/Simple/Program/Run.hs#L177 https://github.com/haskell/cabal/blob/master/Cabal/Distribution/Simple/Program/Db.hs#L344 https://github.com/haskell/cabal/blob/master/Cabal/Distribution/Simple/Configure.hs#L808 From spam at scientician.net Thu Sep 24 17:42:33 2015 From: spam at scientician.net (Bardur Arantsson) Date: Thu, 24 Sep 2015 19:42:33 +0200 Subject: Global Constraints for Cabal and also Release Plan? In-Reply-To: References: Message-ID: On 09/24/2015 05:06 PM, Gershom B wrote: > On September 24, 2015 at 11:01:53 AM, Bardur Arantsson (spam at scientician.net) wrote: >> On 09/22/2015 12:11 AM, Gershom B wrote: >> [--snip--] >>> >>> 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'm not sure I understand... what does CABAL_PATH_PREFIX add over just >> adding whatever is needed to the $PATH before executing cabal? >> >> (Without having looked at the issue thread.) >> >> I'm mainly worried about option-itis... which cabal-install is already >> suffering a lot from. > > This is a fine question. By the way, I realized this might better be served as a cabal-path-prefix option (in cabal config) rather than an env variable, since that is more uniform. > > In any case, the issue is this. Suppose I want to work with MSys2, as MinGHC does. This is what lets me build against various c libraries, even in a windows environment. To do so, I need all the MSys2 tools in my path. So far, so good. > > But? those tools overlap in name with other tools in my path. For example, with my existing cygwin installation. And also with other tools of the same names at times that are the _windows_ versions of those common utilities. > > So, I want MSys2 tools in my path but _only_ when I am building cabal packages, and not otherwise. > > Either I manually modify my env each time I want to build a cabal package, _or_ we teach cabal to be clever and handle it for us, which is the motivation for this. > Just write a little wrapper for cabal which sets the path and calls the "real" cabal...? From gershomb at gmail.com Fri Sep 25 21:42:36 2015 From: gershomb at gmail.com (Gershom B) Date: Fri, 25 Sep 2015 17:42:36 -0400 Subject: Global Constraints for Cabal and also Release Plan? In-Reply-To: References: Message-ID: On September 24, 2015 at 12:16:29 PM, Mikhail Glushenkov (the.dead.shall.rise at gmail.com) wrote: > On 24 September 2015 at 17:56, Gershom B wrote: > > Consider for example if we have a configure build-type, that runs an autoconf script. > It is not enough that the executable we run be in the path, but also that the ?path? available > to the autoconf script be amended as well. > > Yes, 'extra-prog-path' also affects the PATH environment variable of > the programs invoked by cabal-install: > > https://github.com/haskell/cabal/blob/master/Cabal/Distribution/Simple/Program/Run.hs#L177 > https://github.com/haskell/cabal/blob/master/Cabal/Distribution/Simple/Program/Db.hs#L344 > https://github.com/haskell/cabal/blob/master/Cabal/Distribution/Simple/Configure.hs#L808 Ah this looks like it only takes hold for the simple build-type and not ?build-type: configure? for use with autoconf. (i.e. the ?building network? case). I don?t quite see what?s going on in terms of how anything is implemented yet, but I would take it there would be no objections to extending this to handle the ?build-type: configure? case? And of course I?d welcome any pointers as to what needs to be changed to make that work.. -gershom From gershomb at gmail.com Sat Sep 26 02:03:49 2015 From: gershomb at gmail.com (Gershom B) Date: Fri, 25 Sep 2015 22:03:49 -0400 Subject: Global Constraints for Cabal and also Release Plan? In-Reply-To: References: Message-ID: On September 25, 2015 at 5:43:38 PM, Gershom B (gershomb at gmail.com) wrote: > Ah this looks like it only takes hold for the simple build-type and not ?build-type: configure? > for use with autoconf. (i.e. the ?building network? case). I don?t quite see what?s going > on in terms of how anything is implemented yet, but I would take it there would be no objections > to extending this to handle the ?build-type: configure? case? And of course I?d welcome > any pointers as to what needs to be changed to make that work.. And this is now implemented here: https://github.com/haskell/cabal/pull/2840 ?Gershom From the.dead.shall.rise at gmail.com Sat Sep 26 11:29:40 2015 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Sat, 26 Sep 2015 13:29:40 +0200 Subject: Global Constraints for Cabal and also Release Plan? In-Reply-To: References: Message-ID: Hi Gershom, On 22 September 2015 at 00:11, Gershom B wrote: > Any more feedback on this? And also, do we have any plans for an > upcoming Cabal release? Re: next release, I think we should do one in the near future, but I'd like to see some outstanding PRs merged first. I have the following preliminary wishlist: a) Decide what to do about no-reinstall patches (merge/no merge for the time being/wait for Duncan to finish his new hotness). b) Merge gen-bounds (#2774) (modulo bikeshedding). c) Merge #2732 and #2731 (Andres's solver improvements) - needs tests/testing. Maybe someone can help Andres on this. d) Merge your constraints-file patch (#2820) - haven't had time to look at it yet, sorry! e) Test the HTTPS code, esp. on Windows. Can be done as part of beta. See also #2764. f) Merge #2522 (**/* globbing) in some form (requires some work on my part) g) #2829 - Thomas's reconfigure work. Not yet finished AFAICT. h) init-config/'user-config init' command - IIRC there are two PRs implementing the same thing. i) Merge Edsko's foreign library patches (#2540). IIRC, they are good to go but need rebasing. Hopefully haven't forgotten anything!