Redesign 'cabal path' command to account for projects#9583
Redesign 'cabal path' command to account for projects#9583mergify[bot] merged 4 commits intohaskell:masterfrom
Conversation
|
As a bit of background context, this PR is the result of the discussions in https://hackmd.io/mQjghm2zRgWgcyD4XKhBqA.
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. |
821ad8f to
8a23c6e
Compare
656bb6a to
075ba0e
Compare
db5ab38 to
6f637a8
Compare
|
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? |
| compilerPathOutputs <- | ||
| if not $ fromFlagOrDefault False (pathCompiler pathFlags) | ||
| then pure Nothing | ||
| else do | ||
| (compiler, _, progDb) <- runRebuild (distProjectRootDirectory . distDirLayout $ baseCtx) $ configureCompiler verbosity (distDirLayout baseCtx) (projectConfig baseCtx) | ||
| compilerProg <- requireCompilerProg verbosity compiler | ||
| (configuredCompilerProg, _) <- requireProgram verbosity compilerProg progDb | ||
| pure $ Just $ mkCompilerInfo configuredCompilerProg compiler |
There was a problem hiding this comment.
Honestly, I hate this, I much rather would have some kind of rule system like shake, so we could depend on certain targets, in this case project base context.
786f132 to
50ba442
Compare
90bf19d to
db03267
Compare
cc5169f to
48df524
Compare
|
Previously, `cabal path` was only able to query from the global
configuration file, e.g., `~/.cabal/config` or the XDG equivalent.
Adding support for cabal project is a huge boost to usability.
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.
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
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".
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.
We also add an exhaustive test suite for 'cabal path' cmd
We test that each query honours cabal.project files, cli parameters, and
is composable with the other query flags.
We extend the test output normalisers for ghc compiler location and
cabal-install version, as the 'cabal path' command outputs the exact ghc
and ghc-pkg location. In addition, the json output format is versioned
on the cabal-install version.
Currently, we query the cabal-install version on each test normalisation
run. This might be unnecessary expensive, and could be avoided by
introducing a 'cabalProgram' that specifies how the program version can
be found. This way, we can cache the version query.
Add '--cache-home' flag thats shows the cabal's cache root
Rename '--cache-dir' to the more correct '--remote-repo-dir'.
62a44b6 to
58fcbb7
Compare
|
@mergify backport |
❌ No backport have been createdDetailsNo destination branches found |
|
@mergify backport 3.12 |
✅ Backports have been createdDetails
|
* 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.
Adding support for cabal project is a huge boost to usability.
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.
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
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".
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.
We also add an exhaustive test suite for 'cabal path' cmd
We test that each query honours cabal.project files, cli parameters, and
is composable with the other query flags.
We extend the test output normalisers for ghc compiler location and
cabal-install version, as the 'cabal path' command outputs the exact ghc
and ghc-pkg location. In addition, the json output format is versioned
on the cabal-install version.
Currently, we query the cabal-install version on each test normalisation
run. This might be unnecessary expensive, and could be avoided by
introducing a 'cabalProgram' that specifies how the program version can
be found. This way, we can cache the version query.
Add '--cache-home' flag thats shows the cabal's cache root
Rename '--cache-dir' to the more correct '--remote-repo-dir'.
* Update 'cabal path' documentation
* Add changelog.d entry
---------
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
(cherry picked from commit 4a8a7c5)
# Conflicts:
# cabal-install/src/Distribution/Client/Setup.hs
* 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.
Adding support for cabal project is a huge boost to usability.
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.
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
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".
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.
We also add an exhaustive test suite for 'cabal path' cmd
We test that each query honours cabal.project files, cli parameters, and
is composable with the other query flags.
We extend the test output normalisers for ghc compiler location and
cabal-install version, as the 'cabal path' command outputs the exact ghc
and ghc-pkg location. In addition, the json output format is versioned
on the cabal-install version.
Currently, we query the cabal-install version on each test normalisation
run. This might be unnecessary expensive, and could be avoided by
introducing a 'cabalProgram' that specifies how the program version can
be found. This way, we can cache the version query.
Add '--cache-home' flag thats shows the cabal's cache root
Rename '--cache-dir' to the more correct '--remote-repo-dir'.
* Update 'cabal path' documentation
* Add changelog.d entry
---------
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
(cherry picked from commit 4a8a7c5)
* 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.
Adding support for cabal project is a huge boost to usability.
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.
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
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".
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.
We also add an exhaustive test suite for 'cabal path' cmd
We test that each query honours cabal.project files, cli parameters, and
is composable with the other query flags.
We extend the test output normalisers for ghc compiler location and
cabal-install version, as the 'cabal path' command outputs the exact ghc
and ghc-pkg location. In addition, the json output format is versioned
on the cabal-install version.
Currently, we query the cabal-install version on each test normalisation
run. This might be unnecessary expensive, and could be avoided by
introducing a 'cabalProgram' that specifies how the program version can
be found. This way, we can cache the version query.
Add '--cache-home' flag thats shows the cabal's cache root
Rename '--cache-dir' to the more correct '--remote-repo-dir'.
* Update 'cabal path' documentation
* Add changelog.d entry
---------
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
(cherry picked from commit 4a8a7c5)
Redesign 'cabal path' command to account for projects (backport #9583)
* 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.
Adding support for cabal project is a huge boost to usability.
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.
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
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".
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.
We also add an exhaustive test suite for 'cabal path' cmd
We test that each query honours cabal.project files, cli parameters, and
is composable with the other query flags.
We extend the test output normalisers for ghc compiler location and
cabal-install version, as the 'cabal path' command outputs the exact ghc
and ghc-pkg location. In addition, the json output format is versioned
on the cabal-install version.
Currently, we query the cabal-install version on each test normalisation
run. This might be unnecessary expensive, and could be avoided by
introducing a 'cabalProgram' that specifies how the program version can
be found. This way, we can cache the version query.
Add '--cache-home' flag thats shows the cabal's cache root
Rename '--cache-dir' to the more correct '--remote-repo-dir'.
* Update 'cabal path' documentation
* Add changelog.d entry
---------
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
- Command help text ends with full stop Co-Authored-By: Artem Pelenitsyn <[email protected]>
- Command help text ends with full stop Co-Authored-By: Artem Pelenitsyn <[email protected]>
Regen cabal help after #9583
Previously,
cabal pathwas only able to query from the global configuration file, e.g.,~/.cabal/configor 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-pathwhich takes project configuration, such ascabal.projectinto account. Note, the command is still namedcabal path, but for the sake of disambiguation, we refer to this new iteration of the command ascabal 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:
If only a single key is queried, we print only the value, for example:
We expand the
cabal v2-pathto also produce information of the compiler that is going to be used in acabal buildorcabal replinvocation. 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.
QA Notes
The name of the command is
cabal path. It should give the user the option to query certain paths cabal will be using.The following things might be of interest to validate
cabal path --helpinforms the user of its purpose and stability promises.cabal pathshould succeed. Order should not matter and the output does not honour the order of flags.output-format, did the error message when you forget to supply this flag help you figure out how to solve the issue?-z?--cabal-configlocations?cabal pathmust never produce any caching artefacts, i.e. no folder indist-newstyleis ever modified or created. Neither isdist-newstyle.output-formats adequately explained or self-explanatory?Template Α: This PR modifies
cabalbehaviourInclude the following checklist in your PR: