Make ghc-pkg discoverable from ghc executable

[bgamari]

Describe the bug
Currently there is no robust way to locate the ghc-pkg executable corresponding to a particular compiler. For this reason, Cabal currently implements a variety of heuristics to do the same. However, these can end up failing, in particular when the executable name is version-suffixed.

@hasufell and I discussed this some months ago after a ghc-up user encountered this problem, which resulted in GHC #18807. To address this I proposed that ghc --info should report the path to the corresponding ghc-pkg executable. This solves the problem nicely since Cabal already must query --info when configuring a package.

I have put together a very straightforward GHC implementation as !4214. I have also written a quick patch implementing the Cabal support.

My sense is that this is the right solution to the problem. However, I'm also happy to hear alternatives. If there are no objections, I will backport to 8.10.5, 9.0.2, and 9.2.1 such that future users won't encounter this issue in the future.

[phadej]

Does this supersede/obsoletes #6648 or are both valuable?

[hasufell]

I'll try the patch out tomorrow in conjunction with the GHC patch.

I also noticed that we could investigate another workaround in the following function

cabal/Cabal/src/Distribution/Simple/GHC.hs

Lines 267 to 278 in 4f8aeb2

	-- | Given something like /usr/local/bin/ghc-6.6.1(.exe) we try and find a
	-- corresponding ghc-pkg, we try looking for both a versioned and unversioned
	-- ghc-pkg in the same dir, that is:
	--
	-- > /usr/local/bin/ghc-pkg-ghc-6.6.1(.exe)
	-- > /usr/local/bin/ghc-pkg-6.6.1(.exe)
	-- > /usr/local/bin/ghc-pkg(.exe)
	--
	guessGhcPkgFromGhcPath :: ConfiguredProgram
	-> Verbosity -> ProgramSearchPath
	-> IO (Maybe (FilePath, [FilePath]))
	guessGhcPkgFromGhcPath = guessToolFromGhcPath ghcPkgProgram

What if we canonicalize first and then effectively follow the symlink if it is one... that would make us usually end up in the internal ghc directory, which should always work. No?

The advantage of this would be that it's a backwards compatible fix that doesn't need a GHC patch.

@rvl do you know if this could break a nix use case?

[phadej]

@hasufell, that would work. On my machine

Prelude System.Directory> canonicalizePath "/opt/ghc/bin/ghc"
"/opt/ghc/8.6.5/bin/ghc-8.6.5"

Prelude System.Directory> canonicalizePath "/opt/ghc/bin/ghc"
"/opt/ghc/8.6.5/bin/ghc-8.6.5"

I think both ghc --info and your canonicalizePath proposal will break nixpkgs if they (re)wrap ghc-pkg and rely on $PATH, yet if they pass --with-hc-pkg explicitly, then it shouldn't break.

[bgamari]

Does this supersede/obsoletes #6648 or are both valuable?

I think they are essentially duplicates. I just didn't find #6648 until I had already opened this one.

[Mikolaj]

How can we help to move this forward? @bgamari, are your patches alive?

[andreabedini]

Just go out of curiosity, in what cases ghc-pkg path is not the the same as ghc plus -pkg?

[phadej]

Just go out of curiosity, in what cases ghc-pkg path is not the the same as ghc plus -pkg?

• ghc-9.6.2 and ghc-pkg-9.6.2
• ghc-9.8-alpha1 and ghc-pkg-9.8-alpha1

Yes, one could look for suffix etc, but that is a hack (heuristic in OP) which has shown to be unreliable.

[phadej]

FWIW, ghc should also make other stuff discoverable through --info, e.g. the haddock. (It's very hard to build docs with not bundled haddock, I doubt non-haddock-developers are actually ever doing so).

[andreabedini]

Thank you @phadej