"Providing" GHC, cabal-install etc.

[amesgen]

@samhh wrote:

Is there any interest in saying that this package "provides" Cabal, GHC, etc? Though they're not installed by default, I'd like to say that my Haskell packages require Cabal without forcing users to install cabal-install (given how Arch traditionally handles Haskell dependencies).

[amesgen]

That would be very similar to how rustup does it. We would have to add symlinks to /usr/bin for this to work (compare this), but right now, I think you would have to reimplement the logic ghcup uses to look for its binaries (respect GHCUP_INSTALL_BASE_PREFIX/GHCUP_USE_XDG_DIRS/XDG_BIN_HOME).

I am definitely open to do this, but it would probably a good idea to expose this logic upstream. Maybe related to https://gitlab.haskell.org/haskell/ghcup-hs/-/issues/173

[hasufell]

I'm not really sure what the full use case is. Do you want a system-wide ghcup installation? I think creating wrapper scripts in /usr/bin that interact with user files is rather odd.

But you can indeed do a system-wide installation by pointing GHCUP_INSTALL_BASE_PREFIX to something like /var/lib/ and then symlink there. But how you manage permissions and installations etc, I'm not sure.

[amesgen]

I think creating wrapper scripts in /usr/bin that interact with user files is rather odd.

For reference, this is exactly what the ArchLinux-packaged rustup does: rustup provides rust, cargo, rustfmt etc. (which also exist as there own packages, where the files are system-owned), and has symlinks in /usr/bin to the default toolchain variants of the local rustup installation in ~/.rustup.

So I don't think it would be too contrived to do sth similiar for ghcup, but I don't have a strong opinion here.

[hasufell]

Yeah, the upcoming ghcup whereis is probably going to be useful for this case. I'm also trying to make this subcommand as performant as possible, so that it has very low overhead, which would be important if someone uses it in a ghc wrapper script: https://gitlab.haskell.org/haskell/ghcup-hs/-/merge_requests/119

[georgefst]

Is this a good idea? Given the rate of breaking changes in the Haskell ecosystem, it seems quite important that packages get to depend on the versions of GHC and Cabal that they're expecting.

I personally like to keep a separation between using GHCUP for development, and using Pacman for installing executables which just happen to be built in Haskell (Pandoc, HLint...). The two toolchains never interact.

Anyway, I'm no expert in packaging and may be missing something. If Rust does it, then presumably it can't be that bad.

[hasufell]

You can now use a ghc wrapper script, such as /usr/bin/ghc-8.10.7:

#!/bin/sh

exec ghcup run --ghc 8.10.7 ghc -- "$@"