Use text package to decode UTF-8 instead of doing it ourselves

[Bodigrim]

Template Α: This PR modifies behaviour or interface

Include the following checklist in your PR:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
  • Is the change significant? If so, remember to add significance: significant in the changelog file.
• The documentation has been updated, if necessary.
• Manual QA notes have been included.
• Tests have been added. (Ask for help if you don’t know how to write them! Ask for an exemption if tests are too complex for too little coverage!)

[ulysses4ever]

In principle, this looks like the right direction of travel. But I'm wary of the CPP and dependence on an internal text module.

[Bodigrim]

CPP can be avoided if everyone is happy to require text >= 2.0. This would require regenerating bootstrap build plan for GHC 9.2.8, but otherwise I hardly see any drawbacks. Shall we?

[geekosaur]

With all the stuff we already need for bootstrapping, and 9.2.8 being disrecommended due to bugs, I think we should go ahead and bump it if it avoids CPP.

[Bodigrim]

One does not simply update a bootstrap plan. Raised #11464 to discuss.

[geekosaur]

And for what it's worth, I don't see any other text version checks in the codebase.

[ulysses4ever]

Since it's a change to the library, not the tool, I'd be more careful. In particular, I'd only require text>=2.0 after the last GHC shipping text<2.0 falls out of our support window. Thoughts @Mikolaj @mpickering @ffaf1?

[Bodigrim]

In particular, I'd only require text>=2.0 after the last GHC shipping text<2.0 falls out of our support window.

Could you elaborate why? What's the relationship?

[geekosaur]

All I can think of is someone building such an older ghc from source, since that would require the newer text to be a bootlib.

[Bodigrim]

All I can think of is someone building such an older ghc from source, since that would require the newer text to be a bootlib.

If they are building an old GHC from source, surely they are building an old Cabal boot library from the GHC source tree, so all is fine.

(For the record, not a hill I'm going to die on; I'm genuinely curious)

[Mikolaj]

This would require regenerating bootstrap build plan for GHC 9.2.8

We can drop the plan for GHC 9.2.8, even because we already have more plans than we normally offer.

Re requiring new text vs CPP, that's a tough one, in particular, because CPP (and non-strict deps) make it much harder to test all paths in CI. Text 2.0 is 4 years old, so maybe it's time to switch? That obviously needs a major version, asking major lib users ahead of time (especially @mpilgrem and the illustrious distro maintainers) and I may still be missing some old promise or custom around this that @ulysses4ever remembers.

[ulysses4ever]

I don't have any reasoning, just things I came to believe over time, overhearing various talks and reading various ancient threads on this bug tracker (no links, sorry). I'd ask Oleg hadn't he explicitly asked not to ping him on ongoing cabal matters.

For distributors, apart from Mike, I think it'd be prudent to ping @juhp for feedback. Maybe @maralorn could also opine. (Apologies in advance for a rather vague ping.) The question is whether you guys see any issue in Cabal-the-library requiring text>=2.

[Bodigrim]

Text 2.0 is 4 years old, so maybe it's time to switch? That obviously needs a major version, asking major lib users ahead of time (especially @mpilgrem and the illustrious distro maintainers) and I may still be missing some old promise or custom around this that @ulysses4ever remembers.

Stack already requires text>=2.1.3.

text-2.0 has been a boot package since GHC 9.4 and pretty much all major Linux distributives are already shipping it or newer.

[maralorn]

Yeah, I this would be no problem on Nixos.

[Bodigrim]

@ulysses4ever @Mikolaj @geekosaur is this enough of assurances to go ahead with this or do you have further reservations?

[ulysses4ever]

With respect to text 2, yes, thank you!

Is there no way to avoid depending on an internal module?

[geekosaur]

Given that we're using the same replacementChar, couldn't we just use Data.Text.Encoding.decodeUtf8Lenient? (It's also in 2.0, if you're worried about that.)