Swap tarballs caching default to True

These could be cached in ~/.config/ghcup.

Created by: LucianU

Is there any reason why caching isn't the default? I just had to download ghc 3 times, because of some errors during the install process.

It's possible, but since we have no way of deleting old tarballs currently I thought the default better be off. Note that you can easily create an alias, such as alias ghcup='ghcup -c'.

ghcup is also used by a haskell package currently and I'm not sure how this would affect them. @Franciman

Created by: Franciman

The only information we rely upon is where ghcup places ghc binaries. So no problem with tarball caching.

Created by: LucianU

Hm, there's something I don't understand. When you say that you have no way of deleting old tarballs, what tarballs are you referring to?

If ghcup doesn't delete tarballs, what happens when an error occurs during the install process? I'm asking, because since it has to download ghc again, I'm assuming it doesn't have access to what it downloaded during the previous install attempt.

Btw, thank you for creating this tool! It really makes my life easier.

Hm, there's something I don't understand. When you say that you have no way of deleting old tarballs, what tarballs are you referring to?

The tarballs it downloads.

If ghcup doesn't delete tarballs, what happens when an error occurs during the install process? I'm asking, because since it has to download ghc again, I'm assuming it doesn't have access to what it downloaded during the previous install attemp

Of course it has access when you enable caching, otherwise it wouldn't be caching.

The thing is just there is no useful way to determine what tarball the user wants to have cached, which one he doesn't need anymore etc. So there can be only one assumption: cache everything, never delete. So the user has to delete old tarballs he doesn't need anymore himself.

Created by: LucianU

Ok, I had to look at the source, because I felt I didn't express my thoughts clearly, but I didn't know how to phrase it better. So the script saves the tarball in cache dir if caching is enabled. Otherwise, it saves the tarball in a temp dir which it deletes in the post-install clean-up.

Here's how I envision the solution. To me caching the tarball is only useful until you have installed the GHC version you want. After that, you don't need the tarball. I think it's very unlikely that someone wants to keep the tarball around because they might want to uninstall GHC and install it from the cached tarball again.

I see 3 different ways to solve this from less to more work:

• Add a message mentioning the --caching flag when the user runs ghcup install
• Enable caching by default
• If the install process didn't finish successfully, keep the tarball. This relies on the assumption that the user will try again to install the same version and that the tarball didn't cause the install to fail.

I would be fine with the second. The third would be the most inconspicuous for the user, but it could have some pitfalls.

What do you think?

• Add a message mentioning the --caching flag when the user runs ghcup install

Not an option imo. I consider this weird and bad usability to print arbitrary options the user might be interested in. This is a cli tool. Users are expected to run --help. Otherwise, this is something that may be done in documentation (eg Readme).

• Enable caching by default

Yes, this is what I was considering.

• If the install process didn't finish successfully, keep the tarball. This relies on the assumption that the user will try again to install the same version and that the tarball didn't cause the install to fail.

I currently don't know how to do that cleanly. But usability wise this sounds sensible. However, it may still leave unused tarballs.

I've swapped caching only for the bootstrap-haskell script for now. Regular ghcup invocactions will not enable caching. I believe this is a good compromise for now. bootstrap-haskell is primarily usability focused, while ghcup should have the minimum of assumptions.