Add migration guide for #9718 #10578
Conversation
|
Does this need a backport? Or do we always link |
PR haskell#9718 and related PRs reshuffled and refactored Cabal API. This patch adds a simple migration guide for Cabal library users. Authored-by: Maxim Ivanov
ffaf1
force-pushed
the
breaking-changes-3.14
branch
from
7614e7c
to
b4c1f10
Compare
|
Check commit by commit, GitHub rich diff gets confused and messes the diff up. |
Co-authored-by: Maxim Ivanov <[email protected]>
Only master, yes. |
ffaf1
added
squash+merge me
| locations. (Hopefully, avoiding confusion which things should go where and | ||
| how.) | ||
|
|
||
| In your specific circumstance, you'll need to decide how much of that nuance |
There was a problem hiding this comment.
I think it should be pointed out that using getSymbolicPath has some nuance.
- FilePath in
cabal-installis always relative to the project directory which is where cabal-install is run. - SymbolicPath is relative to the package root of the particular package
Cabalis compiling at that time.
For a ./Setup.hs you are probably fine using interpretSymbolicPathCWD, but that is only because cabal-install calls ./Setup in the package directory. If you are writing an application using Cabal library, you might need to take the working directory into account propertly.
There was a problem hiding this comment.
Yep, that basically echoes what the haddocks (+types) say.
I didn't want to overload release notes with deep details; so there's no "do this" code sample, but the call to action is to go check the updated module reference.
There was a problem hiding this comment.
You two have more experience than me with these modules. The warning (“[…] but see the linked module's haddocks for caveats and less drastic options”) seems assertive enough.
Any modification proposal is welcome!
|
Thanks for contributing this @ulidtko |
Include the following checklist in your PR:
Is this a PR that fixes CI? If so, it will need to be backported to older cabal release branches (ask maintainers for directions).Thanks to the excellent doc contribution by @ulidtko in #10559.