From mikhail.glushenkov at gmail.com Wed Feb 14 21:45:42 2018 From: mikhail.glushenkov at gmail.com (Mikhail Glushenkov) Date: Wed, 14 Feb 2018 21:45:42 +0000 Subject: 2.2 release branch created Message-ID: Hi *, I've just created the branch for the 2.2 Cabal/cabal-install release [1]. If everything goes according to plan, the final release will be out approximately in two weeks' time, i.e. around the end of the month. This is a delay of one month compared with the original plan shared in the previous status update [2]. Hopefully, this time there won't be any more additional delays. Cheers, Mikhail [1] https://github.com/haskell/cabal/tree/2.2 [2] https://mail.haskell.org/pipermail/cabal-devel/2017-December/010410.html From gershomb at gmail.com Mon Feb 19 00:25:52 2018 From: gershomb at gmail.com (Gershom B) Date: Sun, 18 Feb 2018 19:25:52 -0500 Subject: draft proposal on provenance-qualified dependencies Message-ID: Hey all, I mentioned (on the long SLURP thread) that I was thinking about a general proposal for provenance-qualified dependencies to reduce coupling in the haskell ecosystem. Having worked it out a bit, I think the bigger win is it also provides a way to specify dependencies on git repos, etc., which has been an oft-requested feature. I don't want to submit it as an ecosystem proposal proper without further polish, and I held off on bugging a larger audience of cabal folks until the 2.2 branch was cut. So now I'm passing this along for further comment and polish before I make a real proposal: https://github.com/gbaz/ghc-proposals/blob/patch-1/proposals/0000-provenance-qualified-imports.rst There's no urgency, but it would be good to get some feedback in the next few weeks if possible. Cheers, Gershom From michael at snoyman.com Tue Feb 20 13:47:37 2018 From: michael at snoyman.com (Michael Snoyman) Date: Tue, 20 Feb 2018 15:47:37 +0200 Subject: Upgrading Stack to Cabal 2.2 Message-ID: Hi all, Oleg mentioned to me on Reddit that a 2.2 branch has been cut for Cabal, and recommended we try to upgrade Stack to it. I'm sharing information here on that process in case it's useful to others, either as feedback on the API changes, or help for others going through similar upgrades. If anyone would rather that I do or do not post such reports in the future, let me know. I've opened a PR for this change[1], which currently is a single commit[2]. As you can see from the change to stack.yaml[3], I needed to refer to the commit of Cabal in question, and turn on `allow-newer` for some packages (cabal-doctest and http-api-data) with restrictive upper bounds on Cabal. Both of these packages compiled without issue. No change was necessary to Stack's Setup.hs file. Most of the changes so far were compile-time errors, which is a Good Thing. Changes I had to make: * The build type is no longer a Maybe field. (As a user: this is a nice change, no longer a need to guess about what a Nothing value means.) * There are now two License types, the original one and the SPDX variant. I don't understand what this change is about, some further explanation in the docs or the ChangeLog would definitely be appreciated. But hacking my way through the types seems to have worked. * Parsing a package description now works on a ByteString instead of a String. This allowed me to remove some UTF8 conversion and BOM-stripping code, which is very nice. * The new parsing API exposes the cabal file version when that prevented the parse (at least, that's my understanding). The changes to accommodate the new API were relatively trivial, so another +1 here. * Also: getting file position information for warnings and errors is _very_ nice. +1 I haven't done extensive testing yet, but I've so far only found one bug due to runtime changes: the behavior of allBuildInfo has changed to now include non-buildable components. This resulted in some confusion until I reviewed the changelog more closely. If I could make a request, it would be that, in the future, new runtime behavior come with a new function name, to convert runtime errors into compile time errors. This was _not_ a particularly difficult issue to work around though, in large part thanks to the changelog. I'll continue testing this branch of Stack. Our plans are to merge this to master, and release Stack 1.7.0 close to the Cabal 2.2 release date. Michael [1] https://github.com/commercialhaskell/stack/pull/3878/files [2] https://github.com/commercialhaskell/stack/pull/3878/commits/a101341d04213d6dd8e0cf16d2f2fef8e7ed5cd5 [3] https://github.com/commercialhaskell/stack/pull/3878/commits/a101341d04213d6dd8e0cf16d2f2fef8e7ed5cd5#diff-fafd0cdcd559a7b124cc61c29413fb54 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Tue Feb 20 14:18:21 2018 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Tue, 20 Feb 2018 15:18:21 +0100 Subject: Upgrading Stack to Cabal 2.2 In-Reply-To: References: Message-ID: On Tue, Feb 20, 2018 at 2:47 PM, Michael Snoyman wrote: > If I could make a request, it would be that, in > the future, new runtime behavior come with a new function name, to convert > runtime errors into compile time errors. Well, this is one of the primary reasons we have the PVP, so we can signal semantic changes via major version bumps even if the types don't change, and avoid cluttering the APIs with new names everytime we want to change semantics. Let's use the benefits of the PVP instead of trying to ways to undermine the purpose of PVP. From oleg.grenrus at iki.fi Tue Feb 20 16:12:41 2018 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Tue, 20 Feb 2018 18:12:41 +0200 Subject: Upgrading Stack to Cabal 2.2 In-Reply-To: References: Message-ID: Hi Michael, thanks for your comments! - The allBuildInfo change is https://github.com/haskell/cabal/commit/8fc10320a5dc4898927c84ad6a2dce7965ef30db, I agree with Herbert on this. New `allBuildInfo` implementation is correct given the name. There was even a TODO to make that change. `reallyAllBuildInfo` would been silly. I also didn't felt ok to change the type to `Traversal` (we have lenses, please try out them too and tell if something is missing!). We'll highlight the change in the changelog, as it's easy to miss. - The lack of SPDX changelog entry is my bad. It was a series of patches, and the changelog + manual update is still not done. I try to summarise:     - `cabal-version: 2.2` files use SPDX expression syntax for `license: ` field. PackageDescription's licenseRaw will be Left expr, expr :: Distribution.SPDX.License.License     - `cabal-version: 2.0` files still use old `License` syntax and type, licenseRaw is `Right l`, l :: Distribution.License.License     - I recommend treating the field as opaque. You can `either display display` to show it        - Next best choice is to use `SPDX.License` as in that direction conversion is lossless (licenseToSPDX), but have to workaround lack of e.g. `OtherLicense` as a concept (IIRC it's converted to LicenseRef:OtherLicense which is valid SPDX-License-Id). This might be necessary if you plan to read (human readable) text back. Oleg On 20.02.2018 15:47, Michael Snoyman wrote: > Hi all, > > Oleg mentioned to me on Reddit that a 2.2 branch has been cut for > Cabal, and recommended we try to upgrade Stack to it. I'm sharing > information here on that process in case it's useful to others, either > as feedback on the API changes, or help for others going through > similar upgrades. If anyone would rather that I do or do not post such > reports in the future, let me know. > > I've opened a PR for this change[1], which currently is a single > commit[2]. As you can see from the change to stack.yaml[3], I needed > to refer to the commit of Cabal in question, and turn on `allow-newer` > for some packages (cabal-doctest and http-api-data) with restrictive > upper bounds on Cabal. Both of these packages compiled without issue. > > No change was necessary to Stack's Setup.hs file. > > Most of the changes so far were compile-time errors, which is a Good > Thing. Changes I had to make: > > * The build type is no longer a Maybe field. (As a user: this is a > nice change, no longer a need to guess about what a Nothing value means.) > * There are now two License types, the original one and the SPDX > variant. I don't understand what this change is about, some further > explanation in the docs or the ChangeLog would definitely be > appreciated. But hacking my way through the types seems to have worked. > * Parsing a package description now works on a ByteString instead of a > String. This allowed me to remove some UTF8 conversion and > BOM-stripping code, which is very nice. > * The new parsing API exposes the cabal file version when that > prevented the parse (at least, that's my understanding). The changes > to accommodate the new API were relatively trivial, so another +1 here. > * Also: getting file position information for warnings and errors is > _very_ nice. +1 > > I haven't done extensive testing yet, but I've so far only found one > bug due to runtime changes: the behavior of allBuildInfo has changed > to now include non-buildable components. This resulted in some > confusion until I reviewed the changelog more closely. If I could make > a request, it would be that, in the future, new runtime behavior come > with a new function name, to convert runtime errors into compile time > errors. This was _not_ a particularly difficult issue to work around > though, in large part thanks to the changelog. > > I'll continue testing this branch of Stack. Our plans are to merge > this to master, and release Stack 1.7.0 close to the Cabal 2.2 release > date. > > Michael > > [1] https://github.com/commercialhaskell/stack/pull/3878/files > [2] > https://github.com/commercialhaskell/stack/pull/3878/commits/a101341d04213d6dd8e0cf16d2f2fef8e7ed5cd5 > [3] > https://github.com/commercialhaskell/stack/pull/3878/commits/a101341d04213d6dd8e0cf16d2f2fef8e7ed5cd5#diff-fafd0cdcd559a7b124cc61c29413fb54 > > > _______________________________________________ > cabal-devel mailing list > cabal-devel at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From michael at snoyman.com Tue Feb 20 17:45:31 2018 From: michael at snoyman.com (Michael Snoyman) Date: Tue, 20 Feb 2018 19:45:31 +0200 Subject: Upgrading Stack to Cabal 2.2 In-Reply-To: References: Message-ID: I'm sorry, I'm not quite sure I understand your recommendation. Are you saying that I should ideally replace all usages of `License` in the Stack codebase with `Either SPDX.License License`? That _should_ be possible, the only questions I'd have are: 1. We additionally grab license info from the GHC package dump. Would there be any problem parsing that license field into the old License data type and storing as Right? 2. If we're going to have to treat this as arbitrary text anyway, is there any reason not to represent it as `newtype TextualLicense = TextualLicense Text` or similar, and convert immediately with `display`? On Tue, Feb 20, 2018 at 6:12 PM, Oleg Grenrus wrote: > Hi Michael, > > thanks for your comments! > > - The allBuildInfo change is > https://github.com/haskell/cabal/commit/8fc10320a5dc4898927c84ad6a2dce > 7965ef30db, > I agree with Herbert on this. New `allBuildInfo` implementation is > correct given the name. There was even a TODO to make that change. > `reallyAllBuildInfo` would been silly. I also didn't felt ok to change > the type to `Traversal` (we have lenses, please try out them too and > tell if something is missing!). We'll highlight the change in the > changelog, as it's easy to miss. > > - The lack of SPDX changelog entry is my bad. It was a series of > patches, and the changelog + manual update is still not done. I try to > summarise: > - `cabal-version: 2.2` files use SPDX expression syntax for > `license: ` field. PackageDescription's licenseRaw will be Left expr, > expr :: Distribution.SPDX.License.License > - `cabal-version: 2.0` files still use old `License` syntax and > type, licenseRaw is `Right l`, l :: Distribution.License.License > - I recommend treating the field as opaque. You can `either display > display` to show it > - Next best choice is to use `SPDX.License` as in that direction > conversion is lossless (licenseToSPDX), but have to workaround lack of > e.g. `OtherLicense` as a concept (IIRC it's converted to > LicenseRef:OtherLicense which is valid SPDX-License-Id). This might be > necessary if you plan to read (human readable) text back. > > Oleg > > On 20.02.2018 15:47, Michael Snoyman wrote: > > Hi all, > > > > Oleg mentioned to me on Reddit that a 2.2 branch has been cut for > > Cabal, and recommended we try to upgrade Stack to it. I'm sharing > > information here on that process in case it's useful to others, either > > as feedback on the API changes, or help for others going through > > similar upgrades. If anyone would rather that I do or do not post such > > reports in the future, let me know. > > > > I've opened a PR for this change[1], which currently is a single > > commit[2]. As you can see from the change to stack.yaml[3], I needed > > to refer to the commit of Cabal in question, and turn on `allow-newer` > > for some packages (cabal-doctest and http-api-data) with restrictive > > upper bounds on Cabal. Both of these packages compiled without issue. > > > > No change was necessary to Stack's Setup.hs file. > > > > Most of the changes so far were compile-time errors, which is a Good > > Thing. Changes I had to make: > > > > * The build type is no longer a Maybe field. (As a user: this is a > > nice change, no longer a need to guess about what a Nothing value means.) > > * There are now two License types, the original one and the SPDX > > variant. I don't understand what this change is about, some further > > explanation in the docs or the ChangeLog would definitely be > > appreciated. But hacking my way through the types seems to have worked. > > * Parsing a package description now works on a ByteString instead of a > > String. This allowed me to remove some UTF8 conversion and > > BOM-stripping code, which is very nice. > > * The new parsing API exposes the cabal file version when that > > prevented the parse (at least, that's my understanding). The changes > > to accommodate the new API were relatively trivial, so another +1 here. > > * Also: getting file position information for warnings and errors is > > _very_ nice. +1 > > > > I haven't done extensive testing yet, but I've so far only found one > > bug due to runtime changes: the behavior of allBuildInfo has changed > > to now include non-buildable components. This resulted in some > > confusion until I reviewed the changelog more closely. If I could make > > a request, it would be that, in the future, new runtime behavior come > > with a new function name, to convert runtime errors into compile time > > errors. This was _not_ a particularly difficult issue to work around > > though, in large part thanks to the changelog. > > > > I'll continue testing this branch of Stack. Our plans are to merge > > this to master, and release Stack 1.7.0 close to the Cabal 2.2 release > > date. > > > > Michael > > > > [1] https://github.com/commercialhaskell/stack/pull/3878/files > > [2] > > https://github.com/commercialhaskell/stack/pull/3878/commits/ > a101341d04213d6dd8e0cf16d2f2fef8e7ed5cd5 > > [3] > > https://github.com/commercialhaskell/stack/pull/3878/commits/ > a101341d04213d6dd8e0cf16d2f2fef8e7ed5cd5#diff- > fafd0cdcd559a7b124cc61c29413fb54 > > > > > > _______________________________________________ > > cabal-devel mailing list > > cabal-devel at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel > > > > _______________________________________________ > cabal-devel mailing list > cabal-devel at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg.grenrus at iki.fi Tue Feb 20 18:02:11 2018 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Tue, 20 Feb 2018 20:02:11 +0200 Subject: Upgrading Stack to Cabal 2.2 In-Reply-To: References: Message-ID: <2197cfef-dace-3803-f7c5-74c507f06ea3@iki.fi> 1. The InstalledPackageInfo license field is also `Either SPDX.License License` [1] and you can get a list of IPIs conviently with `HcPkg.dump` [2] 2. It's up to you, if `Text` is enough, go for it. In the future you might want to provide some license reports, where you'll need structured license information, but then "reverting" `TextualLicense` will be a type-directed, so it's up to you. Oleg - https://github.com/haskell/cabal/blob/32fea06a1023a507d7dc16b29f542538c0b55e46/Cabal/Distribution/Types/InstalledPackageInfo.hs#L50 - https://github.com/haskell/cabal/blob/32fea06a1023a507d7dc16b29f542538c0b55e46/Cabal/Distribution/Simple/Program/HcPkg.hs#L246 On 20.02.2018 19:45, Michael Snoyman wrote: > I'm sorry, I'm not quite sure I understand your recommendation. Are > you saying that I should ideally replace all usages of `License` in > the Stack codebase with `Either SPDX.License License`? That _should_ > be possible, the only questions I'd have are: > > 1. We additionally grab license info from the GHC package dump. Would > there be any problem parsing that license field into the old License > data type and storing as Right? > 2. If we're going to have to treat this as arbitrary text anyway, is > there any reason not to represent it as `newtype TextualLicense = > TextualLicense Text` or similar, and convert immediately with `display`? > > On Tue, Feb 20, 2018 at 6:12 PM, Oleg Grenrus > wrote: > > Hi Michael, > > thanks for your comments! > > - The allBuildInfo change is > https://github.com/haskell/cabal/commit/8fc10320a5dc4898927c84ad6a2dce7965ef30db > , > I agree with Herbert on this. New `allBuildInfo` implementation is > correct given the name. There was even a TODO to make that change. > `reallyAllBuildInfo` would been silly. I also didn't felt ok to change > the type to `Traversal` (we have lenses, please try out them too and > tell if something is missing!). We'll highlight the change in the > changelog, as it's easy to miss. > > - The lack of SPDX changelog entry is my bad. It was a series of > patches, and the changelog + manual update is still not done. I try to > summarise: >     - `cabal-version: 2.2` files use SPDX expression syntax for > `license: ` field. PackageDescription's licenseRaw will be Left expr, > expr :: Distribution.SPDX.License.License >     - `cabal-version: 2.0` files still use old `License` syntax and > type, licenseRaw is `Right l`, l :: Distribution.License.License >     - I recommend treating the field as opaque. You can `either > display > display` to show it >        - Next best choice is to use `SPDX.License` as in that > direction > conversion is lossless (licenseToSPDX), but have to workaround lack of > e.g. `OtherLicense` as a concept (IIRC it's converted to > LicenseRef:OtherLicense which is valid SPDX-License-Id). This might be > necessary if you plan to read (human readable) text back. > > Oleg > > On 20.02.2018 15:47, Michael Snoyman wrote: > > Hi all, > > > > Oleg mentioned to me on Reddit that a 2.2 branch has been cut for > > Cabal, and recommended we try to upgrade Stack to it. I'm sharing > > information here on that process in case it's useful to others, > either > > as feedback on the API changes, or help for others going through > > similar upgrades. If anyone would rather that I do or do not > post such > > reports in the future, let me know. > > > > I've opened a PR for this change[1], which currently is a single > > commit[2]. As you can see from the change to stack.yaml[3], I needed > > to refer to the commit of Cabal in question, and turn on > `allow-newer` > > for some packages (cabal-doctest and http-api-data) with restrictive > > upper bounds on Cabal. Both of these packages compiled without > issue. > > > > No change was necessary to Stack's Setup.hs file. > > > > Most of the changes so far were compile-time errors, which is a Good > > Thing. Changes I had to make: > > > > * The build type is no longer a Maybe field. (As a user: this is a > > nice change, no longer a need to guess about what a Nothing > value means.) > > * There are now two License types, the original one and the SPDX > > variant. I don't understand what this change is about, some further > > explanation in the docs or the ChangeLog would definitely be > > appreciated. But hacking my way through the types seems to have > worked. > > * Parsing a package description now works on a ByteString > instead of a > > String. This allowed me to remove some UTF8 conversion and > > BOM-stripping code, which is very nice. > > * The new parsing API exposes the cabal file version when that > > prevented the parse (at least, that's my understanding). The changes > > to accommodate the new API were relatively trivial, so another > +1 here. > > * Also: getting file position information for warnings and errors is > > _very_ nice. +1 > > > > I haven't done extensive testing yet, but I've so far only found one > > bug due to runtime changes: the behavior of allBuildInfo has changed > > to now include non-buildable components. This resulted in some > > confusion until I reviewed the changelog more closely. If I > could make > > a request, it would be that, in the future, new runtime behavior > come > > with a new function name, to convert runtime errors into compile > time > > errors. This was _not_ a particularly difficult issue to work around > > though, in large part thanks to the changelog. > > > > I'll continue testing this branch of Stack. Our plans are to merge > > this to master, and release Stack 1.7.0 close to the Cabal 2.2 > release > > date. > > > > Michael > > > > [1] https://github.com/commercialhaskell/stack/pull/3878/files > > > [2] > > > https://github.com/commercialhaskell/stack/pull/3878/commits/a101341d04213d6dd8e0cf16d2f2fef8e7ed5cd5 > > > [3] > > > https://github.com/commercialhaskell/stack/pull/3878/commits/a101341d04213d6dd8e0cf16d2f2fef8e7ed5cd5#diff-fafd0cdcd559a7b124cc61c29413fb54 > > > > > > > _______________________________________________ > > cabal-devel mailing list > > cabal-devel at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel > > > > > _______________________________________________ > cabal-devel mailing list > cabal-devel at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From michael at snoyman.com Tue Feb 20 18:28:26 2018 From: michael at snoyman.com (Michael Snoyman) Date: Tue, 20 Feb 2018 20:28:26 +0200 Subject: Upgrading Stack to Cabal 2.2 In-Reply-To: <2197cfef-dace-3803-f7c5-74c507f06ea3@iki.fi> References: <2197cfef-dace-3803-f7c5-74c507f06ea3@iki.fi> Message-ID: Alright, I've updated the PR to use `Either SPDX.License License`: https://github.com/commercialhaskell/stack/pull/3878/commits/6679aafe99a087dd6aac341fce965f4067e1be77 The only difference from your description that I ran into is that there's no Text instance for SPDX.License, meaning instead of: either display display I ended up with display . either licenseFromSPDX id Is it intentional that there is no Text instance for SPDX.License? On Tue, Feb 20, 2018 at 8:02 PM, Oleg Grenrus wrote: > 1. The InstalledPackageInfo license field is also `Either SPDX.License > License` [1] and you can get a list of IPIs conviently with `HcPkg.dump` > [2] > 2. It's up to you, if `Text` is enough, go for it. In the future you > might want to provide some license reports, where you'll need structured > license information, but then "reverting" `TextualLicense` will be a > type-directed, so it's up to you. > > Oleg > > > - > https://github.com/haskell/cabal/blob/32fea06a1023a507d7dc16b29f5425 > 38c0b55e46/Cabal/Distribution/Types/InstalledPackageInfo.hs#L50 > - > https://github.com/haskell/cabal/blob/32fea06a1023a507d7dc16b29f5425 > 38c0b55e46/Cabal/Distribution/Simple/Program/HcPkg.hs#L246 > > > On 20.02.2018 19:45, Michael Snoyman wrote: > > I'm sorry, I'm not quite sure I understand your recommendation. Are > > you saying that I should ideally replace all usages of `License` in > > the Stack codebase with `Either SPDX.License License`? That _should_ > > be possible, the only questions I'd have are: > > > > 1. We additionally grab license info from the GHC package dump. Would > > there be any problem parsing that license field into the old License > > data type and storing as Right? > > 2. If we're going to have to treat this as arbitrary text anyway, is > > there any reason not to represent it as `newtype TextualLicense = > > TextualLicense Text` or similar, and convert immediately with `display`? > > > > On Tue, Feb 20, 2018 at 6:12 PM, Oleg Grenrus > > wrote: > > > > Hi Michael, > > > > thanks for your comments! > > > > - The allBuildInfo change is > > https://github.com/haskell/cabal/commit/ > 8fc10320a5dc4898927c84ad6a2dce7965ef30db > > 8fc10320a5dc4898927c84ad6a2dce7965ef30db>, > > I agree with Herbert on this. New `allBuildInfo` implementation is > > correct given the name. There was even a TODO to make that change. > > `reallyAllBuildInfo` would been silly. I also didn't felt ok to > change > > the type to `Traversal` (we have lenses, please try out them too and > > tell if something is missing!). We'll highlight the change in the > > changelog, as it's easy to miss. > > > > - The lack of SPDX changelog entry is my bad. It was a series of > > patches, and the changelog + manual update is still not done. I try > to > > summarise: > > - `cabal-version: 2.2` files use SPDX expression syntax for > > `license: ` field. PackageDescription's licenseRaw will be Left expr, > > expr :: Distribution.SPDX.License.License > > - `cabal-version: 2.0` files still use old `License` syntax and > > type, licenseRaw is `Right l`, l :: Distribution.License.License > > - I recommend treating the field as opaque. You can `either > > display > > display` to show it > > - Next best choice is to use `SPDX.License` as in that > > direction > > conversion is lossless (licenseToSPDX), but have to workaround lack > of > > e.g. `OtherLicense` as a concept (IIRC it's converted to > > LicenseRef:OtherLicense which is valid SPDX-License-Id). This might > be > > necessary if you plan to read (human readable) text back. > > > > Oleg > > > > On 20.02.2018 15:47, Michael Snoyman wrote: > > > Hi all, > > > > > > Oleg mentioned to me on Reddit that a 2.2 branch has been cut for > > > Cabal, and recommended we try to upgrade Stack to it. I'm sharing > > > information here on that process in case it's useful to others, > > either > > > as feedback on the API changes, or help for others going through > > > similar upgrades. If anyone would rather that I do or do not > > post such > > > reports in the future, let me know. > > > > > > I've opened a PR for this change[1], which currently is a single > > > commit[2]. As you can see from the change to stack.yaml[3], I > needed > > > to refer to the commit of Cabal in question, and turn on > > `allow-newer` > > > for some packages (cabal-doctest and http-api-data) with > restrictive > > > upper bounds on Cabal. Both of these packages compiled without > > issue. > > > > > > No change was necessary to Stack's Setup.hs file. > > > > > > Most of the changes so far were compile-time errors, which is a > Good > > > Thing. Changes I had to make: > > > > > > * The build type is no longer a Maybe field. (As a user: this is a > > > nice change, no longer a need to guess about what a Nothing > > value means.) > > > * There are now two License types, the original one and the SPDX > > > variant. I don't understand what this change is about, some further > > > explanation in the docs or the ChangeLog would definitely be > > > appreciated. But hacking my way through the types seems to have > > worked. > > > * Parsing a package description now works on a ByteString > > instead of a > > > String. This allowed me to remove some UTF8 conversion and > > > BOM-stripping code, which is very nice. > > > * The new parsing API exposes the cabal file version when that > > > prevented the parse (at least, that's my understanding). The > changes > > > to accommodate the new API were relatively trivial, so another > > +1 here. > > > * Also: getting file position information for warnings and errors > is > > > _very_ nice. +1 > > > > > > I haven't done extensive testing yet, but I've so far only found > one > > > bug due to runtime changes: the behavior of allBuildInfo has > changed > > > to now include non-buildable components. This resulted in some > > > confusion until I reviewed the changelog more closely. If I > > could make > > > a request, it would be that, in the future, new runtime behavior > > come > > > with a new function name, to convert runtime errors into compile > > time > > > errors. This was _not_ a particularly difficult issue to work > around > > > though, in large part thanks to the changelog. > > > > > > I'll continue testing this branch of Stack. Our plans are to merge > > > this to master, and release Stack 1.7.0 close to the Cabal 2.2 > > release > > > date. > > > > > > Michael > > > > > > [1] https://github.com/commercialhaskell/stack/pull/3878/files > > > > > [2] > > > > > https://github.com/commercialhaskell/stack/pull/3878/commits/ > a101341d04213d6dd8e0cf16d2f2fef8e7ed5cd5 > > a101341d04213d6dd8e0cf16d2f2fef8e7ed5cd5> > > > [3] > > > > > https://github.com/commercialhaskell/stack/pull/3878/commits/ > a101341d04213d6dd8e0cf16d2f2fef8e7ed5cd5#diff- > fafd0cdcd559a7b124cc61c29413fb54 > > a101341d04213d6dd8e0cf16d2f2fef8e7ed5cd5#diff- > fafd0cdcd559a7b124cc61c29413fb54> > > > > > > > > > _______________________________________________ > > > cabal-devel mailing list > > > cabal-devel at haskell.org > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel > > > > > > > > > > _______________________________________________ > > cabal-devel mailing list > > cabal-devel at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikhail.glushenkov at gmail.com Tue Feb 20 19:50:33 2018 From: mikhail.glushenkov at gmail.com (Mikhail Glushenkov) Date: Tue, 20 Feb 2018 19:50:33 +0000 Subject: Upgrading Stack to Cabal 2.2 In-Reply-To: References: Message-ID: Hi, On 20 February 2018 at 13:47, Michael Snoyman wrote: > Hi all, > > Oleg mentioned to me on Reddit that a 2.2 branch has been cut for Cabal, and > recommended we try to upgrade Stack to it. I'm sharing information here on > that process in case it's useful to others, either as feedback on the API > changes, or help for others going through similar upgrades. If anyone would > rather that I do or do not post such reports in the future, let me know. > > [...] Thanks for sharing this, I've updated the 2.2 migration guide [1] with some of the things you mentioned that weren't already in the guide. Good point about the SPDX changelog entry as well, I'll make sure that this change is documented better before the release. I'll keep the point about `allBuildInfos` in mind. I agree that for the library user it's normally better to get a compile error when there's a backwards-incompatible change, but, as Herbert & Oleg correctly note, from the API design standpoint it can be a bit of a balancing act. [1] https://github.com/haskell/cabal/wiki/2.2-migration-guide From oleg.grenrus at iki.fi Tue Feb 20 20:19:15 2018 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Tue, 20 Feb 2018 22:19:15 +0200 Subject: Upgrading Stack to Cabal 2.2 In-Reply-To: References: <2197cfef-dace-3803-f7c5-74c507f06ea3@iki.fi> Message-ID: <9dbccb42-f820-d9f2-28cd-44c93bffef24@iki.fi> Good point. There aren't ReadP-parser for SPDX.License, so no Text instance either. But there is `Distribution.Pretty.Pretty` instance (`prettyShow`). - Oleg On 20.02.2018 20:28, Michael Snoyman wrote: > Alright, I've updated the PR to use `Either SPDX.License License`: > > https://github.com/commercialhaskell/stack/pull/3878/commits/6679aafe99a087dd6aac341fce965f4067e1be77 > > The only difference from your description that I ran into is that > there's no Text instance for SPDX.License, meaning instead of: > >     either display display > > I ended up with > >     display . either licenseFromSPDX id > > Is it intentional that there is no Text instance for SPDX.License? > > On Tue, Feb 20, 2018 at 8:02 PM, Oleg Grenrus > wrote: > > 1. The InstalledPackageInfo license field is also `Either SPDX.License > License` [1] and you can get a list of IPIs conviently with > `HcPkg.dump` [2] > 2. It's up to you, if `Text` is enough, go for it. In the future you > might want to provide some license reports, where you'll need > structured > license information, but then "reverting" `TextualLicense` will be a > type-directed, so it's up to you. > > Oleg > > > - > https://github.com/haskell/cabal/blob/32fea06a1023a507d7dc16b29f542538c0b55e46/Cabal/Distribution/Types/InstalledPackageInfo.hs#L50 > > - > https://github.com/haskell/cabal/blob/32fea06a1023a507d7dc16b29f542538c0b55e46/Cabal/Distribution/Simple/Program/HcPkg.hs#L246 > > > > On 20.02.2018 19:45, Michael Snoyman wrote: > > I'm sorry, I'm not quite sure I understand your recommendation. Are > > you saying that I should ideally replace all usages of `License` in > > the Stack codebase with `Either SPDX.License License`? That _should_ > > be possible, the only questions I'd have are: > > > > 1. We additionally grab license info from the GHC package dump. > Would > > there be any problem parsing that license field into the old License > > data type and storing as Right? > > 2. If we're going to have to treat this as arbitrary text anyway, is > > there any reason not to represent it as `newtype TextualLicense = > > TextualLicense Text` or similar, and convert immediately with > `display`? > > > > On Tue, Feb 20, 2018 at 6:12 PM, Oleg Grenrus > > > >> wrote: > > > >     Hi Michael, > > > >     thanks for your comments! > > > >     - The allBuildInfo change is > >    >  https://github.com/haskell/cabal/commit/8fc10320a5dc4898927c84ad6a2dce7965ef30db > > >    >   >, > >     I agree with Herbert on this. New `allBuildInfo` > implementation is > >     correct given the name. There was even a TODO to make that > change. > >     `reallyAllBuildInfo` would been silly. I also didn't felt ok > to change > >     the type to `Traversal` (we have lenses, please try out them > too and > >     tell if something is missing!). We'll highlight the change > in the > >     changelog, as it's easy to miss. > > > >     - The lack of SPDX changelog entry is my bad. It was a series of > >     patches, and the changelog + manual update is still not > done. I try to > >     summarise: > >         - `cabal-version: 2.2` files use SPDX expression syntax for > >     `license: ` field. PackageDescription's licenseRaw will be > Left expr, > >     expr :: Distribution.SPDX.License.License > >         - `cabal-version: 2.0` files still use old `License` > syntax and > >     type, licenseRaw is `Right l`, l :: Distribution.License.License > >         - I recommend treating the field as opaque. You can `either > >     display > >     display` to show it > >            - Next best choice is to use `SPDX.License` as in that > >     direction > >     conversion is lossless (licenseToSPDX), but have to > workaround lack of > >     e.g. `OtherLicense` as a concept (IIRC it's converted to > >     LicenseRef:OtherLicense which is valid SPDX-License-Id). > This might be > >     necessary if you plan to read (human readable) text back. > > > >     Oleg > > > >     On 20.02.2018 15:47, Michael Snoyman wrote: > >     > Hi all, > >     > > >     > Oleg mentioned to me on Reddit that a 2.2 branch has been > cut for > >     > Cabal, and recommended we try to upgrade Stack to it. I'm > sharing > >     > information here on that process in case it's useful to > others, > >     either > >     > as feedback on the API changes, or help for others going > through > >     > similar upgrades. If anyone would rather that I do or do not > >     post such > >     > reports in the future, let me know. > >     > > >     > I've opened a PR for this change[1], which currently is a > single > >     > commit[2]. As you can see from the change to > stack.yaml[3], I needed > >     > to refer to the commit of Cabal in question, and turn on > >     `allow-newer` > >     > for some packages (cabal-doctest and http-api-data) with > restrictive > >     > upper bounds on Cabal. Both of these packages compiled without > >     issue. > >     > > >     > No change was necessary to Stack's Setup.hs file. > >     > > >     > Most of the changes so far were compile-time errors, which > is a Good > >     > Thing. Changes I had to make: > >     > > >     > * The build type is no longer a Maybe field. (As a user: > this is a > >     > nice change, no longer a need to guess about what a Nothing > >     value means.) > >     > * There are now two License types, the original one and > the SPDX > >     > variant. I don't understand what this change is about, > some further > >     > explanation in the docs or the ChangeLog would definitely be > >     > appreciated. But hacking my way through the types seems to > have > >     worked. > >     > * Parsing a package description now works on a ByteString > >     instead of a > >     > String. This allowed me to remove some UTF8 conversion and > >     > BOM-stripping code, which is very nice. > >     > * The new parsing API exposes the cabal file version when that > >     > prevented the parse (at least, that's my understanding). > The changes > >     > to accommodate the new API were relatively trivial, so another > >     +1 here. > >     > * Also: getting file position information for warnings and > errors is > >     > _very_ nice. +1 > >     > > >     > I haven't done extensive testing yet, but I've so far only > found one > >     > bug due to runtime changes: the behavior of allBuildInfo > has changed > >     > to now include non-buildable components. This resulted in some > >     > confusion until I reviewed the changelog more closely. If I > >     could make > >     > a request, it would be that, in the future, new runtime > behavior > >     come > >     > with a new function name, to convert runtime errors into > compile > >     time > >     > errors. This was _not_ a particularly difficult issue to > work around > >     > though, in large part thanks to the changelog. > >     > > >     > I'll continue testing this branch of Stack. Our plans are > to merge > >     > this to master, and release Stack 1.7.0 close to the Cabal 2.2 > >     release > >     > date. > >     > > >     > Michael > >     > > >     > [1] > https://github.com/commercialhaskell/stack/pull/3878/files > > >      > > >     > [2] > >     > > >    >  https://github.com/commercialhaskell/stack/pull/3878/commits/a101341d04213d6dd8e0cf16d2f2fef8e7ed5cd5 > > >    >   > > >     > [3] > >     > > >    >  https://github.com/commercialhaskell/stack/pull/3878/commits/a101341d04213d6dd8e0cf16d2f2fef8e7ed5cd5#diff-fafd0cdcd559a7b124cc61c29413fb54 > > >    >   > > >     > > >     > > >     > _______________________________________________ > >     > cabal-devel mailing list > >     > cabal-devel at haskell.org > > > >     > > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel > > >      > > > > > > > > >     _______________________________________________ > >     cabal-devel mailing list > >     cabal-devel at haskell.org > > > >     http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel > > >    >   > > > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From michael at snoyman.com Wed Feb 21 04:12:03 2018 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 21 Feb 2018 06:12:03 +0200 Subject: Upgrading Stack to Cabal 2.2 In-Reply-To: <9dbccb42-f820-d9f2-28cd-44c93bffef24@iki.fi> References: <2197cfef-dace-3803-f7c5-74c507f06ea3@iki.fi> <9dbccb42-f820-d9f2-28cd-44c93bffef24@iki.fi> Message-ID: Got it, thanks. Mikhail: thank you for the feedback too. If you want me to review any updates, let me know. On Tue, Feb 20, 2018 at 10:19 PM, Oleg Grenrus wrote: > Good point. There aren't ReadP-parser for SPDX.License, so no Text > instance either. > But there is `Distribution.Pretty.Pretty` instance (`prettyShow`). > > - Oleg > > > On 20.02.2018 20:28, Michael Snoyman wrote: > > Alright, I've updated the PR to use `Either SPDX.License License`: > > > > https://github.com/commercialhaskell/stack/pull/3878/commits/ > 6679aafe99a087dd6aac341fce965f4067e1be77 > > > > The only difference from your description that I ran into is that > > there's no Text instance for SPDX.License, meaning instead of: > > > > either display display > > > > I ended up with > > > > display . either licenseFromSPDX id > > > > Is it intentional that there is no Text instance for SPDX.License? > > > > On Tue, Feb 20, 2018 at 8:02 PM, Oleg Grenrus > > wrote: > > > > 1. The InstalledPackageInfo license field is also `Either > SPDX.License > > License` [1] and you can get a list of IPIs conviently with > > `HcPkg.dump` [2] > > 2. It's up to you, if `Text` is enough, go for it. In the future you > > might want to provide some license reports, where you'll need > > structured > > license information, but then "reverting" `TextualLicense` will be a > > type-directed, so it's up to you. > > > > Oleg > > > > > > - > > https://github.com/haskell/cabal/blob/32fea06a1023a507d7dc16b29f5425 > 38c0b55e46/Cabal/Distribution/Types/InstalledPackageInfo.hs#L50 > > 32fea06a1023a507d7dc16b29f542538c0b55e46/Cabal/Distribution/ > Types/InstalledPackageInfo.hs#L50> > > - > > https://github.com/haskell/cabal/blob/32fea06a1023a507d7dc16b29f5425 > 38c0b55e46/Cabal/Distribution/Simple/Program/HcPkg.hs#L246 > > 32fea06a1023a507d7dc16b29f542538c0b55e46/Cabal/Distribution/ > Simple/Program/HcPkg.hs#L246> > > > > > > On 20.02.2018 19:45, Michael Snoyman wrote: > > > I'm sorry, I'm not quite sure I understand your recommendation. Are > > > you saying that I should ideally replace all usages of `License` in > > > the Stack codebase with `Either SPDX.License License`? That > _should_ > > > be possible, the only questions I'd have are: > > > > > > 1. We additionally grab license info from the GHC package dump. > > Would > > > there be any problem parsing that license field into the old > License > > > data type and storing as Right? > > > 2. If we're going to have to treat this as arbitrary text anyway, > is > > > there any reason not to represent it as `newtype TextualLicense = > > > TextualLicense Text` or similar, and convert immediately with > > `display`? > > > > > > On Tue, Feb 20, 2018 at 6:12 PM, Oleg Grenrus > > > > > >> wrote: > > > > > > Hi Michael, > > > > > > thanks for your comments! > > > > > > - The allBuildInfo change is > > > > > https://github.com/haskell/cabal/commit/ > 8fc10320a5dc4898927c84ad6a2dce7965ef30db > > 8fc10320a5dc4898927c84ad6a2dce7965ef30db> > > > > > 8fc10320a5dc4898927c84ad6a2dce7965ef30db > > 8fc10320a5dc4898927c84ad6a2dce7965ef30db>>, > > > I agree with Herbert on this. New `allBuildInfo` > > implementation is > > > correct given the name. There was even a TODO to make that > > change. > > > `reallyAllBuildInfo` would been silly. I also didn't felt ok > > to change > > > the type to `Traversal` (we have lenses, please try out them > > too and > > > tell if something is missing!). We'll highlight the change > > in the > > > changelog, as it's easy to miss. > > > > > > - The lack of SPDX changelog entry is my bad. It was a series > of > > > patches, and the changelog + manual update is still not > > done. I try to > > > summarise: > > > - `cabal-version: 2.2` files use SPDX expression syntax for > > > `license: ` field. PackageDescription's licenseRaw will be > > Left expr, > > > expr :: Distribution.SPDX.License.License > > > - `cabal-version: 2.0` files still use old `License` > > syntax and > > > type, licenseRaw is `Right l`, l :: > Distribution.License.License > > > - I recommend treating the field as opaque. You can `either > > > display > > > display` to show it > > > - Next best choice is to use `SPDX.License` as in that > > > direction > > > conversion is lossless (licenseToSPDX), but have to > > workaround lack of > > > e.g. `OtherLicense` as a concept (IIRC it's converted to > > > LicenseRef:OtherLicense which is valid SPDX-License-Id). > > This might be > > > necessary if you plan to read (human readable) text back. > > > > > > Oleg > > > > > > On 20.02.2018 15:47, Michael Snoyman wrote: > > > > Hi all, > > > > > > > > Oleg mentioned to me on Reddit that a 2.2 branch has been > > cut for > > > > Cabal, and recommended we try to upgrade Stack to it. I'm > > sharing > > > > information here on that process in case it's useful to > > others, > > > either > > > > as feedback on the API changes, or help for others going > > through > > > > similar upgrades. If anyone would rather that I do or do not > > > post such > > > > reports in the future, let me know. > > > > > > > > I've opened a PR for this change[1], which currently is a > > single > > > > commit[2]. As you can see from the change to > > stack.yaml[3], I needed > > > > to refer to the commit of Cabal in question, and turn on > > > `allow-newer` > > > > for some packages (cabal-doctest and http-api-data) with > > restrictive > > > > upper bounds on Cabal. Both of these packages compiled > without > > > issue. > > > > > > > > No change was necessary to Stack's Setup.hs file. > > > > > > > > Most of the changes so far were compile-time errors, which > > is a Good > > > > Thing. Changes I had to make: > > > > > > > > * The build type is no longer a Maybe field. (As a user: > > this is a > > > > nice change, no longer a need to guess about what a Nothing > > > value means.) > > > > * There are now two License types, the original one and > > the SPDX > > > > variant. I don't understand what this change is about, > > some further > > > > explanation in the docs or the ChangeLog would definitely be > > > > appreciated. But hacking my way through the types seems to > > have > > > worked. > > > > * Parsing a package description now works on a ByteString > > > instead of a > > > > String. This allowed me to remove some UTF8 conversion and > > > > BOM-stripping code, which is very nice. > > > > * The new parsing API exposes the cabal file version when > that > > > > prevented the parse (at least, that's my understanding). > > The changes > > > > to accommodate the new API were relatively trivial, so > another > > > +1 here. > > > > * Also: getting file position information for warnings and > > errors is > > > > _very_ nice. +1 > > > > > > > > I haven't done extensive testing yet, but I've so far only > > found one > > > > bug due to runtime changes: the behavior of allBuildInfo > > has changed > > > > to now include non-buildable components. This resulted in > some > > > > confusion until I reviewed the changelog more closely. If I > > > could make > > > > a request, it would be that, in the future, new runtime > > behavior > > > come > > > > with a new function name, to convert runtime errors into > > compile > > > time > > > > errors. This was _not_ a particularly difficult issue to > > work around > > > > though, in large part thanks to the changelog. > > > > > > > > I'll continue testing this branch of Stack. Our plans are > > to merge > > > > this to master, and release Stack 1.7.0 close to the Cabal > 2.2 > > > release > > > > date. > > > > > > > > Michael > > > > > > > > [1] > > https://github.com/commercialhaskell/stack/pull/3878/files > > > > > > > > > > > [2] > > > > > > > > > https://github.com/commercialhaskell/stack/pull/3878/commits/ > a101341d04213d6dd8e0cf16d2f2fef8e7ed5cd5 > > a101341d04213d6dd8e0cf16d2f2fef8e7ed5cd5> > > > > > a101341d04213d6dd8e0cf16d2f2fef8e7ed5cd5 > > a101341d04213d6dd8e0cf16d2f2fef8e7ed5cd5>> > > > > [3] > > > > > > > > > https://github.com/commercialhaskell/stack/pull/3878/commits/ > a101341d04213d6dd8e0cf16d2f2fef8e7ed5cd5#diff- > fafd0cdcd559a7b124cc61c29413fb54 > > a101341d04213d6dd8e0cf16d2f2fef8e7ed5cd5#diff- > fafd0cdcd559a7b124cc61c29413fb54> > > > > > a101341d04213d6dd8e0cf16d2f2fef8e7ed5cd5#diff- > fafd0cdcd559a7b124cc61c29413fb54 > > a101341d04213d6dd8e0cf16d2f2fef8e7ed5cd5#diff- > fafd0cdcd559a7b124cc61c29413fb54>> > > > > > > > > > > > > _______________________________________________ > > > > cabal-devel mailing list > > > > cabal-devel at haskell.org > > > > > > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > cabal-devel mailing list > > > cabal-devel at haskell.org > > > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel > > > > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Feb 23 11:26:46 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 23 Feb 2018 11:26:46 +0000 Subject: draft proposal on provenance-qualified dependencies In-Reply-To: References: Message-ID: Gershom Looks like a great idea. Lots of questions though: - I think more motivation would be helpful. E.g. "You are in change of the GHC 8.6 release. Package authors don't want to upload a new version of their packages until 8.6 is out, but you still want to smoke-test 8.6 against their packages. Doing so requires some minor changes (version bounds, changes in base-library APIs etc); so you want to be able to make these changes in a sandbox that won't hurt anyone". Or something like that. Maybe describe other use-cases. It's *much* easier to evaluate a proposal when I'm totally clear what it's for. - Does a particular build have to use packages from one repo only? Or is there something like a "search path"? Thanks! Simon | -----Original Message----- | From: cabal-devel [mailto:cabal-devel-bounces at haskell.org] On Behalf | Of Gershom B | Sent: 19 February 2018 00:26 | To: cabal-devel | Subject: draft proposal on provenance-qualified dependencies | | Hey all, I mentioned (on the long SLURP thread) that I was thinking | about a general proposal for provenance-qualified dependencies to | reduce coupling in the haskell ecosystem. Having worked it out a bit, | I think the bigger win is it also provides a way to specify | dependencies on git repos, etc., which has been an oft-requested | feature. | | I don't want to submit it as an ecosystem proposal proper without | further polish, and I held off on bugging a larger audience of cabal | folks until the 2.2 branch was cut. So now I'm passing this along for | further comment and polish before I make a real proposal: | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu | b.com%2Fgbaz%2Fghc-proposals%2Fblob%2Fpatch-1%2Fproposals%2F0000- | provenance-qualified- | imports.rst&data=04%7C01%7Csimonpj%40microsoft.com%7C64fd20012b9a4b24d | 28508d5772f6cf2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636545967 | 936143539%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi | LCJBTiI6Ik1haWwifQ%3D%3D%7C- | 1&sdata=cH0gNADmzA%2BTkmXZEDY6lLYUTx2D2KX%2B3T8KO%2FvU86s%3D&reserved= | 0 | | There's no urgency, but it would be good to get some feedback in the | next few weeks if possible. | | Cheers, | Gershom | _______________________________________________ | cabal-devel mailing list | cabal-devel at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h | askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fcabal- | devel&data=04%7C01%7Csimonpj%40microsoft.com%7C64fd20012b9a4b24d28508d | 5772f6cf2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636545967936143 | 539%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi | I6Ik1haWwifQ%3D%3D%7C- | 1&sdata=fgfMNTNt%2BwEQ5PaTKxtl0bmO7wDv9sBiMUnWSbJhcnE%3D&reserved=0 From gershomb at gmail.com Fri Feb 23 15:01:59 2018 From: gershomb at gmail.com (Gershom B) Date: Fri, 23 Feb 2018 10:01:59 -0500 Subject: draft proposal on provenance-qualified dependencies In-Reply-To: References: Message-ID: Thanks for these comments Simon. It is good to have a sanity-check on these proposals before they go before a broad audience. I'll try to take them into account and submit this properly as a proposal (including creating the associated discussion thread) in the next few days. If anyone else has any thoughts (bear in mind this involves cross-cutting changes across cabal files and a bit of ghc) please send them on. On "Does a particular build have to use packages from one repo only?" -- the idea is that _per package_ a provenance may be specified to a specific repo. If no provenance is specified, then there is the current existing "search path-like" functionality where a chain of overlays may live over a repo. The proposal does not address that, because it is how things work already -- although arguably, the way in which this works may be insufficiently understood among existing cabal users? (In fact, looking at the cabal documentation, I see that the description of multiple remote repos doesn't specify the manner in which they are combined, which it should). Cheers, Gershom On Fri, Feb 23, 2018 at 6:26 AM, Simon Peyton Jones wrote: > Gershom > > Looks like a great idea. > > Lots of questions though: > > > - I think more motivation would be helpful. E.g. "You are in change > of the GHC 8.6 release. Package authors don't want to upload a new > version of their packages until 8.6 is out, but you still want to > smoke-test 8.6 against their packages. Doing so requires some minor > changes (version bounds, changes in base-library APIs etc); so you > want to be able to make these changes in a sandbox that won't hurt > anyone". Or something like that. > > Maybe describe other use-cases. It's *much* easier to evaluate > a proposal when I'm totally clear what it's for. > > - Does a particular build have to use packages from one repo only? > Or is there something like a "search path"? > > Thanks! > > Simon > > | -----Original Message----- > | From: cabal-devel [mailto:cabal-devel-bounces at haskell.org] On Behalf > | Of Gershom B > | Sent: 19 February 2018 00:26 > | To: cabal-devel > | Subject: draft proposal on provenance-qualified dependencies > | > | Hey all, I mentioned (on the long SLURP thread) that I was thinking > | about a general proposal for provenance-qualified dependencies to > | reduce coupling in the haskell ecosystem. Having worked it out a bit, > | I think the bigger win is it also provides a way to specify > | dependencies on git repos, etc., which has been an oft-requested > | feature. > | > | I don't want to submit it as an ecosystem proposal proper without > | further polish, and I held off on bugging a larger audience of cabal > | folks until the 2.2 branch was cut. So now I'm passing this along for > | further comment and polish before I make a real proposal: > | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu > | b.com%2Fgbaz%2Fghc-proposals%2Fblob%2Fpatch-1%2Fproposals%2F0000- > | provenance-qualified- > | imports.rst&data=04%7C01%7Csimonpj%40microsoft.com%7C64fd20012b9a4b24d > | 28508d5772f6cf2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636545967 > | 936143539%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi > | LCJBTiI6Ik1haWwifQ%3D%3D%7C- > | 1&sdata=cH0gNADmzA%2BTkmXZEDY6lLYUTx2D2KX%2B3T8KO%2FvU86s%3D&reserved= > | 0 > | > | There's no urgency, but it would be good to get some feedback in the > | next few weeks if possible. > | > | Cheers, > | Gershom > | _______________________________________________ > | cabal-devel mailing list > | cabal-devel at haskell.org > | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h > | askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fcabal- > | devel&data=04%7C01%7Csimonpj%40microsoft.com%7C64fd20012b9a4b24d28508d > | 5772f6cf2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636545967936143 > | 539%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi > | I6Ik1haWwifQ%3D%3D%7C- > | 1&sdata=fgfMNTNt%2BwEQ5PaTKxtl0bmO7wDv9sBiMUnWSbJhcnE%3D&reserved=0 From simonpj at microsoft.com Fri Feb 23 16:03:52 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 23 Feb 2018 16:03:52 +0000 Subject: draft proposal on provenance-qualified dependencies In-Reply-To: References: Message-ID: | current existing "search path-like" functionality where a chain of | overlays may live over a repo. The proposal does not address that, | because it is how things work already -- although arguably, the way in | which this works may be insufficiently understood among existing cabal | users? Well I can say with certainty that it's insufficiently understood by /this/ cabal user. I had no idea there could be more than one repo, which 'cabal update' caches locally. Simon | -----Original Message----- | From: Gershom B [mailto:gershomb at gmail.com] | Sent: 23 February 2018 15:02 | To: Simon Peyton Jones | Cc: cabal-devel | Subject: Re: draft proposal on provenance-qualified dependencies | | Thanks for these comments Simon. It is good to have a sanity-check on | these proposals before they go before a broad audience. I'll try to | take them into account and submit this properly as a proposal | (including creating the associated discussion thread) in the next few | days. If anyone else has any thoughts (bear in mind this involves | cross-cutting changes across cabal files and a bit of ghc) please send | them on. | | On "Does a particular build have to use packages from one repo only?" | -- the idea is that _per package_ a provenance may be specified to a | specific repo. If no provenance is specified, then there is the | current existing "search path-like" functionality where a chain of | overlays may live over a repo. The proposal does not address that, | because it is how things work already -- although arguably, the way in | which this works may be insufficiently understood among existing cabal | users? (In fact, looking at the cabal documentation, I see that the | description of multiple remote repos doesn't specify the manner in | which they are combined, which it should). | | Cheers, | Gershom | | On Fri, Feb 23, 2018 at 6:26 AM, Simon Peyton Jones | wrote: | > Gershom | > | > Looks like a great idea. | > | > Lots of questions though: | > | > | > - I think more motivation would be helpful. E.g. "You are in change | > of the GHC 8.6 release. Package authors don't want to upload a | new | > version of their packages until 8.6 is out, but you still want to | > smoke-test 8.6 against their packages. Doing so requires some | minor | > changes (version bounds, changes in base-library APIs etc); so you | > want to be able to make these changes in a sandbox that won't hurt | > anyone". Or something like that. | > | > Maybe describe other use-cases. It's *much* easier to evaluate | > a proposal when I'm totally clear what it's for. | > | > - Does a particular build have to use packages from one repo only? | > Or is there something like a "search path"? | > | > Thanks! | > | > Simon | > | > | -----Original Message----- | > | From: cabal-devel [mailto:cabal-devel-bounces at haskell.org] On | > | Behalf Of Gershom B | > | Sent: 19 February 2018 00:26 | > | To: cabal-devel | > | Subject: draft proposal on provenance-qualified dependencies | > | | > | Hey all, I mentioned (on the long SLURP thread) that I was | thinking | > | about a general proposal for provenance-qualified dependencies to | > | reduce coupling in the haskell ecosystem. Having worked it out a | > | bit, I think the bigger win is it also provides a way to specify | > | dependencies on git repos, etc., which has been an oft-requested | > | feature. | > | | > | I don't want to submit it as an ecosystem proposal proper without | > | further polish, and I held off on bugging a larger audience of | cabal | > | folks until the 2.2 branch was cut. So now I'm passing this along | > | for further comment and polish before I make a real proposal: | > | | > | | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit | > | hu | > | b.com%2Fgbaz%2Fghc-proposals%2Fblob%2Fpatch-1%2Fproposals%2F0000- | > | provenance-qualified- | > | | > | | imports.rst&data=04%7C01%7Csimonpj%40microsoft.com%7C64fd20012b9a4b2 | > | 4d | > | | > | | 28508d5772f6cf2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6365459 | > | 67 | > | | 936143539%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz | > | Ii | > | LCJBTiI6Ik1haWwifQ%3D%3D%7C- | > | | > | | 1&sdata=cH0gNADmzA%2BTkmXZEDY6lLYUTx2D2KX%2B3T8KO%2FvU86s%3D&reserve | > | d= | > | 0 | > | | > | There's no urgency, but it would be good to get some feedback in | > | the next few weeks if possible. | > | | > | Cheers, | > | Gershom | > | _______________________________________________ | > | cabal-devel mailing list | > | cabal-devel at haskell.org | > | | > | | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail | > | .h | > | askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fcabal- | > | | > | | devel&data=04%7C01%7Csimonpj%40microsoft.com%7C64fd20012b9a4b24d2850 | > | 8d | > | | > | | 5772f6cf2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6365459679361 | > | 43 | > | | 539%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB | > | Ti | > | I6Ik1haWwifQ%3D%3D%7C- | > | | 1&sdata=fgfMNTNt%2BwEQ5PaTKxtl0bmO7wDv9sBiMUnWSbJhcnE%3D&reserved=0