Closed ezzieyguywuf closed 3 years ago
Hi @ezzieyguywuf, could you please provide some details, which versions of GHC and cabal-install
are currently used in Gentoo packages?
Sure.
We're up to ghc 8.10.3 and cabal-install 3.2.0.0
Thanks @ezzieyguywuf for your reply! I tried to bump changes and to pass test-cases on GHC 8.8 with cabal-install 3.2.0.0
and it brings some challenges among the way:
ghc-pkg
should be pointed out explicitly.fay-base
path should be specified explicitly.aeson
major version bump) actual JSON
results contain extra newline characters, so I have to decide how to align tests preserving compatibility with earlier aeson
version. tests/serialization.hs: FAIL (0.94s)
src/tests/Tests.hs:120:
tests/serialization.hs
expected: "{ instance: 'Parametric',\n slot1: { instance: 'ConcreteRecord', concreteField: 123 } }\n{ instance: 'Parametric',\n slot1: { instance: 'ConcreteRecord', concreteField: 123 } }\n{ instance: 'Parametric',\n slot1: { instance: 'ConcreteRecord', concreteField: 123 } }\n{ instance: 'Just',\n slot1: { instance: 'ConcreteRecord', concreteField: 42 } }\n{ instance: 'Just',\n slot1: { instance: 'ConcreteRecord', concreteField: 42 } }\n{ instance: 'Just',\n slot1: { instance: 'ConcreteRecord', concreteField: 42 } }\n42\n{ instance: 'Just', slot1: 42 }\n{ instance: 'Just',\n slot1: { instance: 'ConcreteRecord', concreteField: 42 } }\n"
but got: "{\n instance: 'Parametric',\n slot1: { instance: 'ConcreteRecord', concreteField: 123 }\n}\n{\n instance: 'Parametric',\n slot1: { instance: 'ConcreteRecord', concreteField: 123 }\n}\n{\n instance: 'Parametric',\n slot1: { instance: 'ConcreteRecord', concreteField: 123 }\n}\n{\n instance: 'Just',\n slot1: { instance: 'ConcreteRecord', concreteField: 42 }\n}\n{\n instance: 'Just',\n slot1: { instance: 'ConcreteRecord', concreteField: 42 }\n}\n{\n instance: 'Just',\n slot1: { instance: 'ConcreteRecord', concreteField: 42 }\n}\n42\n{ instance: 'Just', slot1: 42 }\n{\n instance: 'Just',\n slot1: { instance: 'ConcreteRecord', concreteField: 42 }\n}\n"
I will continue investigation and share progress with you.
I saw the same thing with the newlines, my working theory is that it has to do with newer base-compat, but I haven't not really dug into it too much
Regarding ghc-pkg and fay-base, i didn't run into issues here, but maybe I got lucky because of newer GHC?
Finally, since we're talking about fay-base...
I did run into a circular dependency issue with fay-tests and fay-base.
This should probably be a separate issue, but is it possible to:
library fay
into a single module (i think this will
fix my circular dependency issue)I'm happy to help however I can, please let me know
Thanks for collaboration. I will also cross-check base-compat
for this particular reason.
fay
package contains the compiler, fay-base
contains an alternative base
(Prelude
included) that could be compiled with both GHC
and fay
. cabal
via test-suite
stanza.base
test-cases and move fay-base
cases into corresponding test-suite
. Let me make an assessment for these activities. As of now, my plan is roughly following:
cabal-install 3.2.0.0
.fay-base
test errors.fay-tests
to test-suite
. fay
and fay-base
test suites.What do you think about proposed plan?
What do you think about proposed plan?
😍
v2
-style build was causing missing fay-base package errors
. Fay executable was not able to determine fay-base
package location since v2-build
stores package into Cabal Store (yet another package database).cabal v2-exec -- ghc-pkg --package-db ./dist-newstyle/packagedb/ghc-$(ghc --numeric-version) list
I was able to get broken package database with fay
and fay-base
that could not be repaired.The solution for CI pipeline was to force v1-install
(I do realise that it is a subject of deprecation in next releases). For now it fixes following points:
cabal-install 3.2.0.0
.fay-base
test errors.
3 out of 268 tests failed (103.37s)
@swamp-agr thanks for the updates.
Regarding your v2
-style issues, I think this is similar to the issues I was seeing with packaging in gentoo as well.
I didn't dig too much into the code, but this is sort of where my suggestion to wrap up the lib:fay
and lib:fay-base
into a single module came from.
Also, I noticed that fay-base
was moved into this repository from outside - can you elaborate on why this change was made?
I have a feel that simply restructuring the project a bit will help with the v2
-style issues, and probably solve my gentoo problems as well.
Hi @ezzieyguywuf, thank you for comments.
v2
issues. They needed to investigate further. From what I can observe right now, some mechanics of --base-path
argument violated, i.e. I cannot find package sources, while with v1
installation sources stored in $HOME/.cabal/share/$ARCH-$OS-ghc-$GHCVERSION/fay-base-X.X.X.X/src
and could be located via ghc-pkg
.fay-text
, but to be honest, I could be wrong. I joined as maintainer a bit later, maybe @bergmark could bring more light on the reasons.Sure, let's see if @bergmark can provide more background. I have a feeling that whatever the dependency issues were, there's a better fix.
Again, I'm not expert, but just looking at the project structure and comparing to other projects I've seen, my gut tells me that this is where the opportunity for improvement lies.
@ezzieyguywuf if you don't mind, feel free to check Hackage and close this issue.
Specifically, I have ran the test suite with the following with no issues:
aeson-1.5.4.1
base-compat-0.11.2
tasty-1.2.3
By relaxing these upper bounds, and releasing a new version, we will be better able to maintain the gentoo package.