Relax bounds on functor-infix (again)

[414owen]

Prior art: #202

The package seems to load fine with GHC 8.10.2, but not GHC 9.x:

src/Data/Functor/Infix/TH.hs:32:18: error:
    • Couldn't match type: flag0 -> TyVarBndr flag0
                     with: TyVarBndr Language.Haskell.TH.Syntax.Specificity
      Expected: [TyVarBndr Language.Haskell.TH.Syntax.Specificity]
        Actual: [flag0 -> TyVarBndr flag0]
    • In the first argument of ‘ForallT’, namely ‘variables’
      In the second argument of ‘($)’, namely
        ‘ForallT variables constraints type_’
      In a stmt of a 'do' block:
        pure $ ForallT variables constraints type_
   |
32 |   pure $ ForallT variables constraints type_
   |                  ^^^^^^^^^

The author is unresponsive. See fmap/functor-infix#4

Could we maybe update the bounds to base >= 4.7 && < 4.15, template-haskell >= 2.8 && < 2.16?

The docs on hackage are also pretty messed up. They render weirdly, and the type signatures are wrong. The type signature of <$$> should be (<$$>) :: (Functor f1, Functor f2) => (a -> b) -> f1 (f2 a) -> f1 (f2 b). If it's not too much of a hassle, would a trustee be able to regenerate/reupload the hackage docs?

For people who stumble upon this issue, I recommend checking whether composition-extra provides what you need.
It's a lot less likely to break, as it doesn't use TH. It works with GHC {8,9}.*, whereas functor-infix only works with GHC 8.*.

[sjakobi]

I've performed the revision: https://hackage.haskell.org/package/functor-infix-0.0.5/revisions/.

[sjakobi]

Since the maintainer seems not to be active on GitHub, I've notified them via email about the revision.

[414owen]

Thanks @sjakobi

[414owen]

@sjakobi would you be able to regenerate / reupload the docs for functor-infix?

They're pretty messed up. Mathjax is interpreting $$$$ as... something weird, in the type signatures.

I've regenerated the docs locally, and they've fixed the issue, so it would be great to get the hackage docs updated.

[sjakobi]

@414owen I don't want to invest much time into this since it currently seems unlikely that this package will have many users due to its current bounds.

I can delete the current haddocks and trigger regeneration, although I'm not sure whether there are any preconditions for me as a Hackage trustee to do this.

Did you even check whether the latest haddock gives better output at all? EDIT: I see you did.

[sjakobi]

Since the maintainer seems not to be active on GitHub, I've notified them via email about the revision.

Unfortunately my emails to vi@computational.law and me@vikramverma.com could not be delivered.

[andreasabel]

@414owen, just in case the maintainer remains unreachable, would you be willing to take over maintainership?

[414owen]

@andreasabel Yes, I can take over maintainership.

[andreasabel]

Great, @414owen ! This is the takeover procedure: https://wiki.haskell.org/Taking_over_a_package

If you cannot contact the author/maintainer

1. Try to contact the maintainer. Give him/her reasonable time to respond.
2. State your intention to take over the package in a public forum (we recommend the haskell-cafe and/or libraries list). CC the maintainer.
3. Wait a while.
4. Send an email to the hackage administrators (hackage-admin@haskell.org), with a link to the public email thread.
5. The admins will grant you maintenance rights or upload a patched version for you.

From time of announcement of intention to takeover to actual takeover, there will be a 2-6 week period where the admins give the maintainer a chance to respond, with the exact time in any case up to the discretion of the admins.

[414owen]

Hmm, looking at a reverse dependency lookup, it seems that functor-infix only has one hackage package depending on it that isn't owned by vi.

There might be some non-hackage packages too, like GRIN, but I've PRed GRIN to use composition-extra instead.

I suggest that, instead of a maintainership takeover, we add an unmaintained message to the hackage docs of functor-infix, and link people to composition-extra. This will lead to a less fragmented ecosystem. I don't think it's unreasonable. It's quite an easy migration to composition-extra.

[andreasabel]

Sounds good. Doing takeover procedure isn't worth it, I suppose, to revive a fringe package.