Changelogs 3.18

[ffaf1]

I have not added a “Unresolved” section yet. added
Once we decide how to deal with all regressions I will incorporate the relevant changelogs or add to the “Unresolved” section. Then (and only then) we can backport this to master.

---

• Patches conform to the coding conventions.
• no. Is this a PR that fixes CI? If so, it will need to be backported to older cabal release branches (ask maintainers for directions).

[Bodigrim]

Might be easier to land #12055 first, or it will be a pain to backport.

[Mikolaj]

Thank you all for your reviews. Could you kindly re-review now that @ffaf1 answered the questions?

[Bodigrim]

I've been migrating my projects to support Cabal 3.18 (see Bodigrim/cabal-add@08b7913). Here are a few breaking changes, which are not reflected in the changelogs.

• Distribution.Parsec.Error used to contain only PError and showPError. Now it also includes PErrorWithSource and showPErrorWithSource, both lacking @since pragma and AFAICT missing from changelogs.

  Further, runParseResult used to return NonEmpty PError, but now it is NonEmpty PErrorWithSource. Again, I cannot find this mentioned in the changelog.

• readProjectConfig now requires an additional argument ProjectFileParser. While the changelog discusses changes to cabal.project parsing (under "Replace cabal project parsing with parsec parser"), it does not mention explicitly that this function changed its type.

  Even more concerningly, the changelog says that in the next release we will remove the legacy parser, so presumably ProjectFileParser argument will be gone again. This is awful, breaking API twice only to do a full circle. Could we just go ahead and drop the legacy parser already?

• In the same area, the type synonym ProjectConfigSkeleton has changed its meaning from CondTree ConfVar [ProjectConfigPath] ProjectConfig to CondTree ConfVar ([(Maybe URI, ProjectConfigPath)], ProjectConfig). Again, this should be at least briefly mentioned in the changelog, perhaps under the same section as above.

[philderbeast]

• the type synonym ProjectConfigSkeleton has changed its meaning

@Bodigrim, sorry I missed that¹ in the changelog for #10933. Here's the diff:

- type ProjectConfigSkeleton = CondTree ConfVar ([ProjectConfigPath], ProjectConfig)
+ type ProjectConfigSkeleton = CondTree ConfVar ([(Maybe URI, ProjectConfigPath)], ProjectConfig)

Footnotes

1. I should have checked hoogle. Even though library users would pick up the change via the type synonym, those that use the explicit type it was a synonym for wouldn't be so lucky. ↩

[Bodigrim]

@philderbeast to be clear, my concern is not a breaking change per se: I fully recognise that the nature of cabal-install is that its API is rather fluent. My issue is just that the changelog does not mention it explicitly.

[Mikolaj]

@Bodigrim: thank you for spotting the missing mention of breakage. Could you identify from which PRs the first two come?

In particular, I don't remember the parser decision any more. Maybe we could ask the author.

[ulysses4ever]

Generally, we have failed to find a satisfactory solution for the problem of tracking api changes (we discussed it several times, and there was a solution based on print-api, but I also learned recently that streamly folks have their own solution based on haddock-for-hoogle, I think). Cabal is big and manually tracking those changes looks like a nightmare. Anyone who comes up with a robust automated solution will be my hero!

[ffaf1]

Backports are in.

I have also added the missing changes (main culprit being #8889), plus added an “Unresolved” section with a lone regression.

[Mikolaj]

May I ask for the last round of reviews, please?

[Bodigrim]

I have also added the missing changes (main culprit being #8889), plus added an “Unresolved” section with a lone regression.

I cannot find it, git diff origin/3.18 ffaf1/changelogs-3.18 | grep Unresolved returns no matches?..

[ffaf1]

Thanks, I forgot to push that commit. It is in the PR now!