Incompatible with LTS nightly (GHC 8.6.1)?

[orome]

MissingH is no longer part in LTS Haskell after GHC 8.6.1, and attempting to include it in builds manually results in an error due to the requirement base <4.12.

• Can the requirement be relaxed so that it can be included manually?
• Would that change alone allow reinstatement into LTS, or are there other, substantive, incompatibilities?

[jgoerzen]

I would be happy to relax that. Can you tell if an unversioned base dep works with the nightly?

[orome]

Meaning

extra-deps: MissingH

instead of

extra-deps: MissingH-1.4.0.1

in stack.yaml?

[jgoerzen]

No, I mean the dependency on base. If it is working with newer base, the <4.12 restriction could be removed

[orome]

I'm not sure how to do that.

(BTW, when you're relaxing the dependency, you probably want to update the copyright date through 2018.)

[orome]

Is there an ETA for when MissingH will be restored to LTS Haskell (by relaxing the base requirement)?

[jgoerzen]

I could make a new missingh release today if someone can confirm if this does the trick.

John

On Oct 6, 2018, at 11:32 AM, orome notifications@github.com wrote:

Is there an ETA for when MissingH will be restored to LTS Haskell (by relaxing the base requirement)?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[jgoerzen]

Looking at this now. The requirement is:

base >= 4.5, base < 5

It looks like this change was made in Hackage by Revision 1 made by HerbertValerioRiedel at Tue Aug 14 22:12:59 UTC 2018 . I'm not sure why.

[orome]

But not in the Hackage version (so LTS rejects it). Right?

[orome]

Here's what happens when I use the version from this repo (commit 390c0eb); that is, using that version alongside LTS-nightly (from which MissingH is, well, missing, because of the constraint on base in the Hackage version).

[jgoerzen]

Looks like there were some changes in Control.Monad.Fail.MonadFail that are causing a build failure. I would happily apply a patch to address this. Unfortunately, with the base being rather a moving target, I don't have an environment to test this on and don't have time to set one up.

I have, incidentally, recently posted to haskell-cafe looking for a maintainer to take over this (and my other Haskell packages). If anyone reading this would like to do so, feel free to let me know.

[orome]

It would be great if MissingH could make it back into LTS. If it's not there, I won't be the only package that will get kicked out along with it!

[jgoerzen]

Thanks @tvh for a patch. 1.4.1.0 uploaded with the fix.

[orome]

MissingH still doesn't work with nightly:

$ stack init --resolver nightly
Looking for .cabal or package.yaml files to use to init the project.
Using cabal packages:
- ./

Selected resolver: nightly-2018-10-14
Selected resolver: nightly-2018-10-14
Resolver 'nightly-2018-10-14' does not have all the packages to match your requirements.
    errorcall-eq-instance not found
        - MissingH requires -any
    testpack not found
        - MissingH requires -any

[jgoerzen]

FWIW, Those packages are only required for the test suite, not the library itself.

[orome]

I assume that MissingH needs to make it back to nightly for my package (and may others) to make it back in; or will crypto-enigma be excluded by this?

[jgoerzen]

As I've said, I'm trying to find a new maintainer for this package. I don't have the time to put into maintaining it right now. If you'd like to volunteer... ;-)

[orome]

Understood. My question was more of a general one about LTS: if

1. package A requires package B, and
2. package A works when package B is installed as an extra-dep on top of LTS-X.Y, but
3. package B itself is not in LTS-X.Y,

does package A have to be excluded from LTS-X.Y (even if the only reason B is excluded is because of a test suite dependency)?