Redesign 'cabal path' command to account for projects
Previously, cabal path was only able to query from the global configuration file, e.g., ~/.cabal/config or the XDG equivalent. This was deemed not useful enough to warrant a new cabal command, which is a user facing change.
We take the foundations and turn them into cabal v2-path which takes project configuration, such as cabal.project into account. Note, the command is still named cabal path, but for the sake of disambiguation, we refer to this new iteration of the command as cabal v2-path.
In addition, we add support for multiple output formats, such as key-value pairs and json. Specifying the output format is currently mandatory. This allows us to postpone the decision of the default output format and encourages users to explicitly specify the output format in the future, too.
The json output format is versioned by the cabal-install version, which is part of the json object. Thus, all result objects contain at least the key "cabal-install-version".
The key-value pair output prints a line for each queried key and its respective value:
key1: value2
key2: value2
If only a single key is queried, we print only the value, for example:
value1
We expand the cabal v2-path to also produce information of the compiler that is going to be used in a cabal build or cabal repl invocation. To do that, we rebuild the install plan and query for the configured compiler program.
This is helpful for downstream tools, such as HLS, to figure out the GHC version required to compile a project with.
Please read Github PR Conventions and then fill in one of these two templates.
Template Α: This PR modifies cabal behaviour
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.
- [ ] 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!)
As a bit of background context, this PR is the result of the discussions in https://hackmd.io/mQjghm2zRgWgcyD4XKhBqA.
It unifies the cabal status command with cabal path, hopefully producing something that is useful to everyone.
~~The flag compiler-info still causes solving for dependencies, but I couldn't figure out yet how to avoid that elegantly.~~ Fixed :confetti_ball: However, we also need to write out the hcPkgPath.
More tests are yet to come (also a POC that it actually helps hie-bios and HLS's startup time), but since I expect a solid amount of bikeshedding, I open the PR now.
This is ready for review now! I want to add a couple of tests. Is there any chance this could land in 3.12 or is that going to be released soon?
Specifying the output format is currently mandatory. This allows us to postpone the decision of the default output format and encourages users to explicitly specify the output format in the future, too.
cabal is UI first and foremost. Forcing users to pick an output format is an antifeature. Scripters can specify the json format once in their script and move on with their lives.
I also have a preference for tools that produce human-readable output by default. I think it is a nice experience if cabal path without any extra arguments prints all the places cabal looks for (and writes) files, in a way that even a novice user can reasonably understand. It is also easier to deal with in ad-hoc shell scripts. Of course, a --json option (or whatever) is useful for less ad-hoc scripting.
@chreekat By default, now cabal path will use the key-value output format.
@mergify backport
backport
❌ No backport have been created
No destination branches found
@mergify backport 3.12
backport 3.12
✅ Backports have been created
-
#9893 Redesign 'cabal path' command to account for projects (backport #9583) has been created for branch
3.12but encountered conflicts