`cabal list` requires `ghc`, no way to specify alternative version

[claudeha]

Describe the bug
cabal list needs a ghc executable (why?). I can't specify which version, eg ghc-8.10.1.

To Reproduce

$ cabal-3.2.0.0 list containers
cabal-3.2.0.0: The program 'ghc' version >=7.0.1 is required but it could not
be found.
$ cabal-3.2.0.0 -w ghc-8.10.1 list containers
cabal-3.2.0.0: unrecognised command: ghc-8.10.1 (try --help)
$ cabal-3.2.0.0 list -w ghc-8.10.1 containers
cabal-3.2.0.0: unrecognized 'list' option `-w'

Expected behavior
If cabal list needs a ghc, to have some way of specifying the version.

System information

• Debian Buster
• cabal-3.2.0.0, ghc-8.10.1

Additional context
I install ghc from bindist with prefix ~/opt/ghc/$GHCVERSION, and symlink the versioned executables into ~/opt/bin which is in my $PATH. I don't have a binary/link named ghc without a version, but that is a bit beside the point for this bug report (if I did, there would still be no way to specify the version).

[phadej]

GHC is required to show which versions are installed. Though that's less useful for nix-style builds, as there are hardly anything installed in global database.

@hvr, should we drop --installed feature from list, if it's intention is to be Search the index.

[hvr]

@phadej I tend to agree; it's much easier to have cabal list have its scope limited to operate only on the package index by default rather than operating on package databases.

as there are hardly anything installed in global database.

Actually, not when you use common Linux distros which package up ghc and about a thousand of Haskell packages; then your pre-installed package-db will easily have hundreds of packages provided by your linux distro.

In any case, I think cabal list ought not to crash and burn when there's no ghc in $PATH, or it should at least give a way to operate without any ghc available.

So there's s a strawman suggestion:

1. Have cabal list not try to invoke ghc by default
2. Teach a -w flag to cabal list, which only when provided will cause cabal list to reach out to ghc

This has the benefit, that by default cabal list operates as if there was a cabal list --no-installed flag; and we can still recover the current semantics by explicitly invoking with cabal list -w ghc

Fwiw, the current --help text still mentions sandboxes...

List packages matching a search string.

Usage: cabal list [FLAGS]
   or: cabal list [FLAGS] STRINGS

List all packages, or all packages matching one of the search strings.

If there is a sandbox in the current directory and config:ignore-sandbox is
False, use the sandbox package database. Otherwise, use the package database
specified with --package-db. If not specified, use the user package database.

[phadej]

Sandboxes are not yet removed, and I’m tired trying to push for their removal. Communicating the removal, making surveys, backporting fixes to older cabal-install versions (cf comment on my recent PR). I start to think we just have to live with them.

…

On 3. May 2020, at 12.45, Herbert Valerio Riedel ***@***.***> wrote:  @phadej I tend to agree; it's much easier to have cabal list have its scope limited to operate only on the package index by default rather than operating on package databases. as there are hardly anything installed in global database. Actually, not when you use common Linux distros which package up ghc and about a thousand of Haskell packages; then your pre-installed package-db will easily have hundreds of packages provided by your linux distro. In any case, I think cabal list ought not to crash and burn when there's no ghc in $PATH, or it should at least give a way to operate without any ghc available. So there's s a strawman suggestion: Have cabal list not try to invoke ghc by default Teach a -w flag to cabal list, which only when provided will cause cabal list to reach out to ghc This has the benefit, that by default cabal list operates as if there was a cabal list --no-installed flag; and we can still recover the current semantics by explicitly invoking with cabal list -w ghc Fwiw, the current --help text still mentions sandboxes... List packages matching a search string. Usage: cabal list [FLAGS] or: cabal list [FLAGS] STRINGS List all packages, or all packages matching one of the search strings. If there is a sandbox in the current directory and config:ignore-sandbox is False, use the sandbox package database. Otherwise, use the package database specified with --package-db. If not specified, use the user package database. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.