'Data.Map.fromList' throws error #180
Comments
|
I see you are using cabal. What version of proto-lens do you have installed? We are pegged at version proto-lens-0.2.2.0 and don't support the newest version yet, so I suspect that is the issue. |
|
@fkm3 I don't think that your proposed explanation is correct. I have the same issue when trying to build with nixos 18.03, it pegs proto-lens-0.2.2.0 too. |
|
Are you getting this same error? Or, are you getting the error reported in #190? |
|
This is also being discussed on haskell-cafe: https://mail.haskell.org/pipermail/haskell-cafe/2018-May/129103.html I'm not sure what exactly to blame, but a bunch of weird things are coinciding to bring you this error:
If I 'cabal get' the package, delete the generated Haskell modules, and repackage it (with tar --format=ustar, since everything else makes cabal explode), it does actually start working again (Cabal-2.0.1.1, proto-lens-protoc-0.2.2.3, proto-lens-0.2.2.0), because the chosen version of proto-lens-protoc is used to generate the modules. Unfortunately cabal and stack become very unhappy if you try to 'sdist' packages that mention Haskell files that don't exist, so the release process for packages that include modules generated by proto-lens is to generate the code, then 'sdist' them, which means the generated code is included in the uploads. It might be appropriate to update the version bounds on the affected packages to require a version of proto-lens that's compatible with the included generated code (in this case, proto-lens <0.2.2) -- but if older versions of cabal can still compile against other versions, this would be unnecessarily restrictive. It might also make sense to work around this by releasing a new tensorflow-proto version that's had the generated modules removed, and mark 0.1.0.0 as deprecated. |
This makes it possible to generate tarballs without generated modules (which would be regenerated anyway when the package is build). See tensorflow/haskell#180 for an example of the issues that causes.
This makes it possible to generate tarballs without generated modules (which would be regenerated anyway when the package is build). See tensorflow/haskell#180 for an example of the issues that causes. Unfortunately, this required us stopping using `hpack` in our packages that generate proto files. `hpack`, when you use the `autogen-modules` field, `cabal-version: >= 2.0` when the file I mitigated the situation a little by changing the Cabal test script to only try to `sdist` packages that we're planning to release.
This makes it possible to generate tarballs without generated modules (which would be regenerated anyway when the package is build). See tensorflow/haskell#180 for an example of the issues that causes. For `Cabal-1.*`, this continues the behavior as before. Unfortunately, `hpack` requires `cabal-version: >=2.0` when you use its `generated-modules` or `generated-other-modules` fields. Our current set of LTSes that we support still includes `Cabal-1.*` (which I think is correct). Luckily we could work around that using `hpack`'s `verbatim` field to accomplish the same thing a little more verbosely. Additionally, I mitigated the situation a little by changing the Cabal test script to not `sdist` packages that we're not releasing (`proto-lens-{tests/benchmarks}`).
This makes it possible to generate tarballs without generated modules (which would be regenerated anyway when the package is build). See tensorflow/haskell#180 for an example of the issues that causes. For `Cabal-1.*`, this continues the behavior as before. Unfortunately, `hpack` requires `cabal-version: >=2.0` when you use its `generated-modules` or `generated-other-modules` fields. Our current set of LTSes that we support still includes `Cabal-1.*` (which I think is correct). Luckily we could work around that using `hpack`'s `verbatim` field to accomplish the same thing a little more verbosely. Additionally, I mitigated the situation a little by changing the Cabal test script to not `sdist` packages that we're not releasing (`proto-lens-{tests/benchmarks}`). This change required bumping `stack` to `1.7.1` in order to get new enough versions of `Cabal` and `hpack`.
This makes it possible to generate tarballs without generated modules (which would be regenerated anyway when the package is build). See tensorflow/haskell#180 for an example of the issues that causes. For `Cabal-1.*`, this continues the behavior as before. Unfortunately, `hpack` requires `cabal-version: >=2.0` when you use its `generated-modules` or `generated-other-modules` fields. Our current set of LTSes that we support still includes `Cabal-1.*` (which I think is correct). Luckily we could work around that using `hpack`'s `verbatim` field to accomplish the same thing a little more verbosely. Additionally, I mitigated the situation a little by changing the Cabal test script to not `sdist` packages that we're not releasing (`proto-lens-{tests/benchmarks}`). This change required bumping `stack` to `1.7.1` in order to get new enough versions of `Cabal` and `hpack`. Happily, it greatly simplifies the steps for releasing our packages.
This makes it possible to generate tarballs without generated modules (which would be regenerated anyway when the package is build). See tensorflow/haskell#180 for an example of the issues that causes. For `Cabal-1.*`, this continues the behavior as before. Unfortunately, `hpack` requires `cabal-version: >=2.0` when you use its `generated-modules` or `generated-other-modules` fields. Our current set of LTSes that we support still includes `Cabal-1.*` (which I think is correct). Luckily we could work around that using `hpack`'s `verbatim` field to accomplish the same thing a little more verbosely. Additionally, I mitigated the situation a little by changing the Cabal test script to not `sdist` packages that we're not releasing (`proto-lens-{tests/benchmarks}`). This change required bumping `stack` to `1.7.1` in order to get new enough versions of `Cabal` and `hpack`. Happily, it greatly simplifies the steps for releasing our packages.
This makes it possible to generate tarballs without generated modules (which would be regenerated anyway when the package is build). See tensorflow/haskell#180 for an example of the issues that causes. For `Cabal-1.*`, this continues the behavior as before. Unfortunately, `hpack` requires `cabal-version: >=2.0` when you use its `generated-modules` or `generated-other-modules` fields. Our current set of LTSes that we support still includes `Cabal-1.*` (which I think is correct). Luckily we could work around that using `hpack`'s `verbatim` field to accomplish the same thing a little more verbosely. Additionally, I mitigated the situation a little by changing the Cabal test script to not `sdist` packages that we're not releasing (`proto-lens-{tests/benchmarks}`). This change required bumping `stack` to `1.7.1` in order to get new enough versions of `Cabal` and `hpack`. Happily, it greatly simplifies the steps for releasing our packages.
|
@awpr thanks for pinpointing the problem with the sdist file. I've created google/proto-lens#185 to use the For |
This makes it possible to generate tarballs without generated modules (which would be regenerated anyway when the package is build). See tensorflow/haskell#180 for an example of the issues that causes. For `Cabal-1.*`, this continues the behavior as before. Unfortunately, `hpack` requires `cabal-version: >=2.0` when you use its `generated-modules` or `generated-other-modules` fields. Our current set of LTSes that we support still includes `Cabal-1.*` (which I think is correct). Luckily we could work around that using `hpack`'s `verbatim` field to accomplish the same thing a little more verbosely. Additionally, I mitigated the situation a little by changing the Cabal test script to not `sdist` packages that we're not releasing (`proto-lens-{tests/benchmarks}`). This change required bumping `stack` to `1.7.1` in order to get new enough versions of `Cabal` and `hpack`. Happily, it greatly simplifies the steps for releasing our packages.
* Fix #185: Support and use autogen-modules. This makes it possible to generate tarballs without generated modules (which would be regenerated anyway when the package is build). See tensorflow/haskell#180 for an example of the issues that causes. For `Cabal-1.*`, this continues the behavior as before. Unfortunately, `hpack` requires `cabal-version: >=2.0` when you use its `generated-modules` or `generated-other-modules` fields. Our current set of LTSes that we support still includes `Cabal-1.*` (which I think is correct). Luckily we could work around that using `hpack`'s `verbatim` field to accomplish the same thing a little more verbosely. Additionally, I mitigated the situation a little by changing the Cabal test script to not `sdist` packages that we're not releasing (`proto-lens-{tests/benchmarks}`). This change required bumping `stack` to `1.7.1` in order to get new enough versions of `Cabal` and `hpack`. Happily, it greatly simplifies the steps for releasing our packages. * More README updates
|
i've tried all sorts of workarounds for this on MacOs and Fedora, i assume that this is still an issue and not fixed yet? Or do i have to pull in some specific protoc/proto-lens versions. unfortunately i'm a beginner in the haskell ecosystem and don't understand how to make it compile. |
|
I've released a new version to hackage, so the generated files should align with the newest proto-lens version that we claim to support. Does that fix the issue your experiencing? I'd have done what @awpr and @judah suggested, but I'm not too familiar with the intricacies of cabal, so I was afraid I'd do more harm than good. |
* Fix google#185: Support and use autogen-modules. This makes it possible to generate tarballs without generated modules (which would be regenerated anyway when the package is build). See tensorflow/haskell#180 for an example of the issues that causes. For `Cabal-1.*`, this continues the behavior as before. Unfortunately, `hpack` requires `cabal-version: >=2.0` when you use its `generated-modules` or `generated-other-modules` fields. Our current set of LTSes that we support still includes `Cabal-1.*` (which I think is correct). Luckily we could work around that using `hpack`'s `verbatim` field to accomplish the same thing a little more verbosely. Additionally, I mitigated the situation a little by changing the Cabal test script to not `sdist` packages that we're not releasing (`proto-lens-{tests/benchmarks}`). This change required bumping `stack` to `1.7.1` in order to get new enough versions of `Cabal` and `hpack`. Happily, it greatly simplifies the steps for releasing our packages. * More README updates
I've tried to install tensorflow v0.1.0.2, but it throws the following errors.
I'm on macOS High Sierra and have installed all the tools mentioned in the script.
Any ideas?
The text was updated successfully, but these errors were encountered: