serokell / universum

:milky_way: Prelude written in @Serokell
MIT License
176 stars 26 forks source link

[#214] Update supported GHC versions #216

Closed gromakovsky closed 5 years ago

gromakovsky commented 5 years ago

Description

Problem:

  1. We do not explicitly support latest GHC (8.6.*), which is bad because we claim to support at least 3 latest versions.
  2. GHC-7.10.3 which we explicitly support is rather old and for some reason CI build with GHC-7.10.3 fails. In general it imposes some maintenance overhead with no big benefit.

Solution: Support for 7.10.3 is dropped, support for 8.6.5 is added.

  1. Update tested GHC versions in .cabal.
  2. Update stack.yaml files.
  3. Add stack.yaml.lock which is a new feature of Stack.
  4. Update Travis config.

Related issues(s)

Fixes #214

✓ Checklist for your Pull Request

Related changes (conditional)

Stylistic guide (mandatory)

volhovm commented 5 years ago

So it does compile on nixos now or what? :)

gromakovsky commented 5 years ago

I don't know whether it compiles on nixos, but I've fixed universum-doctest with newer GHC. If you have any other issues on nixos, let me know.

volhovm commented 5 years ago

The current issue is different:

Preprocessing test suite 'universum-test' for universum-1.5.0..
Building test suite 'universum-test' for universum-1.5.0..
[1 of 2] Compiling Test.Universum.Property ( test/Test/Universum/Property.hs, dist/build/universum-test/universum-test-tmp/Test/Universum/Property.o )

test/Test/Universum/Property.hs:34:10: error:
    • Couldn't match type ‘Hedgehog.Internal.Gen.GenBase m’
                     with ‘Identity’
        arising from a use of ‘Gen.unicode’
    • In a stmt of a 'do' block: a <- Gen.unicode
      In the expression:
        do a <- Gen.unicode
           if U.elem a ['\65534', ....] then unicode' else return a
      In an equation for ‘unicode'’:
          unicode'
            = do a <- Gen.unicode
                 if U.elem a [...] then unicode' else return a
    • Relevant bindings include
        unicode' :: m Char (bound at test/Test/Universum/Property.hs:33:1)
   |
34 |     a <- Gen.unicode
   |          ^^^^^^^^^^^
gromakovsky commented 5 years ago

Okay, try again.

volhovm commented 5 years ago

I can't just "try again" because it doesn't reproduce on my PC when locally cloned, but instead happens with the revision that is hackage-cloned to nixpkgs.

gromakovsky commented 5 years ago

Okay, but can you/did you review the changes from this PR? Is ability to build it on nixos the only thing you want to be added in this PR?

P. S. I've completely reimplemented by last commit.

gromakovsky commented 5 years ago

Yes, GitHub won't let me merge it without 2 approvals anyway.

gromakovsky commented 5 years ago

If @Martoon-00 wants to make #213 mergeable, he probably should review this PR :wink:

Martoon-00 commented 5 years ago

Replace -qq with -q and remove --force-yes, using those is apparently not recommended by manual

Which manual do you refer to? Regarding -y, I have seen they advising using it in Travis tutorial

gromakovsky commented 5 years ago

@Martoon-00 -y and --force-yes are different flags. I am talking about this manual: https://linux.die.net/man/8/apt-get

-q, --quiet
    Quiet. Produces output suitable for logging, omitting progress indicators. More q's will produce more quiet up to a maximum of two. You can also use -q=# to set the quiet level, overriding the configuration file. Note that quiet level 2 implies -y, you should never use -qq without a no-action modifier such as -d, --print-uris or -s as APT may decided to do something you did not expect. 

you should never use -qq without a no-action modifier such as -d, --print-uris or -s as APT may decided to do something you did not expect.

AFAIU, we don't use such modifiers. And with -q the output doesn't seem to be verbose anyway.

--force-yes
    Force yes. This is a dangerous option that will cause apt-get to continue without prompting if it is doing something potentially harmful. It should not be used except in very special situations. Using --force-yes can potentially destroy your system! 

I think we don't care about possibility of destroying the system (because it's not our own system), but I don't think that our situation is very special and since everything works without this flag I'd rather not use it.