New tool: cabal-cache

[hasufell]

I'm planning to support installation of cabal-cache: https://github.com/haskell-works/cabal-cache

Reason being that it's mainly a tool for CI and it's sorta difficult to get all the right binaries. Compiling it from source in an action doesn't make much sense, since it's supposed to reduce CI time, not increase it.

Some concerns:

• it's not a widely used tool like the others
• our version parsing is so lax that cabal-cache can be parsed as tool cabal with version cache. That's a feature, but will cause problems now.
• we now have 3 binary-only tools: cabal, stack, cabal-cache. This will need heavy refactoring to avoid more code duplication. We need to abstract over this.

@newhoggy

[newhoggy]

That's awesome! Let me know if I can help.

[mpickering]

I think it would be good to consult with the community before deciding to distribute another tool with ghcup. I think an end-user seeing anything distributed with ghcup has an expectation that the tool is official/standard in some sense and I'm not sure that cabal-cache fits that description yet.

[hasufell]

I think an end-user seeing anything distributed with ghcup has an expectation that the tool is official/standard in some sense

Sure, we can source community opinions, but ghcup after all is a distribution channel and a distribution channel is not locked into specific projects.

I'm not very convinced of the "official tool" argument. First of all, there's no clear definition of what that means. Cabal and stack and ghcup are all tools created by individuals. Some of those tools moved to github haskell space, some didn't.

I'm happy to make this more clear to end users during installation.

[hasufell]

One way to solve this tension is to add alternative lesser-known tools to a separate release channel (metadata file... just like the pre-release file).

So they won't show up by default and we can maintain and communicate different expectations.

[Mikolaj]

I haven't thought deeply about all that, but my cheap shot would be that some newcomers might think, e.g,, "hmm, cabal and cabal-cache, that sounds like a set, I want the complete experience and I want my compilations cached, so I have to install both and configure and customize and debug both". Of course, a cursory glance at the first sentence of cabal-cache README or hackage description immediately clears that confusion. But once the confusion sets in and/or is shared among users, it may not be easy to eradicate it (see "Haskell extensions are mutually incompatible different versions of the Haskell programming language"). I can already hear "with Rust you just need rustup, cargo and rustc, but with Haskell you need ghcup, cabal, cabal-cache, GHC, HLS, stack and who knows what else". I suppose it makes sense to add hlint later on, etc., making the confused list longer.

I think a part of the problem is that ghcup does not display even 3-word descriptions of packages it provides (at least in ghcup tui). I suppose adding "CI" to the name of cabal-cache would also do the trick, but working with a different upstream name and in-ghcup name would be unfortunately and one more hurdle for users ("why is it named differently? are there two versions?").

OTOH, a separate release channel seems like too much gate-keeping to just clear the confusion "do I need it on my first Haskell installation and can I afford to skip it and install later on without ripping off everything and starting from scratch?".

[bgamari]

I agree that we should somehow distinguish tools like cabal and ghc from things like cabal-cache to avoid user confusion. However, I think this can be done pretty easily with good user-interface design.

Specifically, groups of tools (e.g. ghcup, ghc, and cabal) are currently shown in ghcup tui separated by horizontal rules. Perhaps just showing a briefly description line in each group describing what each tool and its target audience would be sufficient to clear up any confusion.

[hasufell]

How exactly should we distinguish the tools? Because I think users don't care about "official" (whatever that means). They care about support. And I can guarantee good support for cabal-cache (I'm co-maintainer).

[Mikolaj]

I guess many first-time users care about "how few components can I get away with and still get the standard Haskell experience with good defaults, ideally no configuration from my part needed, unless my platform is exotic or customized". Where "standard" may be defined by the ability to actively follow common modern Haskell tutorials. If you chat with the authors of the few most popular and regularly updated video and text tutorials and you all agree cabal-cache is what they'd recommend and briefly explain in their (supplementary) material, I think cabal-cache is standard. If Haskell doesn't have such tutorials (I haven't checked for years), I guess imagination is what remains.

[hasufell]

If you chat with the authors of the few most popular and regularly updated video and text tutorials and you all agree cabal-cache is what they'd recommend and briefly explain in their (supplementary) material, I think cabal-cache is standard.

I'm not sure I'm going to go on such a hunt of defining what "standard" is. cabal-cache is not standard in any sense.

We could however define a section for "Haskell toolchain", because that we indeed have defined: https://www.haskell.org/downloads/

[Mikolaj]

"Minimal viable Haskell toolchain" may be what I'm talking about.

[ulysses4ever]

I think separate channel is exactly the right solution here. If cabal-cache is used by someone settng up a CI, they will probably have an adequate impression of what it entails. And newcomers probably won't bother adding a channel, nor they really need cabal-cache (or any other tool aside from the toolchain as defined by the Downloads page) all that much.

[ulysses4ever]

And a big +1 for short descriptions of tools in TUI. Although it's not urgent if the main channel only have the basic tools.