Allow text>=2.1, include GHC 9.8.1 in CI

[andreasabel]

Successful CI run here: https://github.com/andreasabel/string-qq/actions/runs/7362971923

[andreasabel]

Published as revision 1 on hackage.

[Vekhir]

@audreyt Is there something that blocks this PR being merged and adding support for GHC 9.8 to string-qq?

[andreasabel]

@Vekhir wrote:

Is there something that blocks this PR being merged and adding support for GHC 9.8 to string-qq?

I thought the revision was sufficient to enable support for GHC 9.8, or is there something missing still?

[Vekhir]

@andreasabel Your revision is fine, what I'm asking for is slightly different, as I'm coming from Arch packaging.

Since Arch provides Haskell packages as system packages, we cannot use cabal and instead build them via runhaskell and using the releases as uploaded to Hackage. The version bounds are contained therein and are still checked, so upgrades occasionally break due to restrictive versions. But the most convenient situation, for me, is when the bounds in the release are compatible with the other packages in the repos.
When bounds are too restrictive, there are ways to circumvent them. The most important tool for that is uusi. Using it looks like this. It adds a dependency (uusi) and the prepare function. It's also a rather blunt device, in that it removes all version checking for that package. Not convenient, but sometimes necessary.
When disabling version checks, we orient ourselves on Hackage revisions as a sanity check that it doesn't break anything else. Insofar are they a valuable resource and I'm glad for the work you are doing. Thanks!

Ultimately though, the upstream source is what ends up in the next release, so even if I can't convince everyone to make a release on version bumps (which would also eliminate most revisions I think), I can at least work towards having the latest version bounds upstream, so the workaround with uusi can be removed on the next release.

And that's what I'm asking for. The wording of my question is supposed to provide context if they only read the email.

[andreasabel]

If you download a package with cabal get, you will get a tarball with revisions included in the .cabal file. Is that an option for you?

[audreyt]

Thank you! Published as 0.0.6.

[Vekhir]

@andreasabel Sources are straight HTTP downloads whose content never changes. The package is then built from that source with minimal dependencies, since every dependency upgrade means a rebuild.
The cabal command is generally not an option, as it has to be built and installed as a system package first, and its dependencies cannot depend on it for bootstrapping reasons. It's mostly unnecessary anyway when using the runhaskell command included with GHC.

Revisions themselves are a workaround, resulting from the convention within the Haskell community to explicitly define which versions are supported/tested/known to work. As they get outdated, they have to be updated - being a material change, the principled thing to do would be to make a new release (thanks @audreyt). The workaround part is that some projects stop being maintained despite being compatible, so the version bumps don't occur. So someone makes a revision to keep things running.
    Revisions are systematically misused/abused in my opinion. Above case occurs very rarely, less than 5% of manual revisions I have to make fall in this category. The other revisions are "convenience revisions", they are made solely because people don't want to create a new release. To some extent I understand why people think this way - A release is work, takes space on Hackage, needs to be tested, and so on. Revisions are easy and can be done by other people. And version bumps aren't really changes, are they? Yes, they are!

Sorry for the rant. I just had to get this out there.
-- Vekhir

[andreasabel]

@Vekhir wrote:

Sources are straight HTTP downloads whose content never changes.

In that definition, what you would need is a URL that gives you a Haskell package with revision applied, which would make this into a release.
So, if hackage would understand a download request for https://hackage.haskell.org/package/string-qq-0.0.5/string-qq-0.0.5~1.tar.gz (observe the ~1 for revision 1!), would that solve your problem with revisions? Then, could we understand a revision as a proper release with version number 0.0.5~1 ?

(If that is the case, your problem could be fixed at the root by extending the hackage-server ...)

[Vekhir]

@andreasabel wrote:

if hackage would understand a download request for https://hackage.haskell.org/package/string-qq-0.0.5/string-qq-0.0.5~1.tar.gz (observe the ~1 for revision 1!), would that solve your problem with revisions?

I think that would be a nice feature to have. It would make working with revisions a lot simpler.
On the Arch side, we'd have to come up with a version translation, though it's not unheard of. I'm not sure ~ are allowed in pkgver, but replacing that with _ isn't an issue, - isn't allowed and we worked around that easily. On the more verbose side, something like qt5-base 5.15.12+kde+r150 could be an option.

At this point, the conversation has gone quite far from the title, would you be so kind and open an issue for the feature over at hackage-server and link it here? We could then continue the discussion there. I'm overall in favour of the feature.

I'm tagging @felixonmars, he's an experienced Arch package maintainer and maintains most Haskell packages. He can expand on the Arch side of things and maybe bring in points I haven't thought of.