Add flag to disable network access

Currently, as an example, ghcup set ghc 8.8.4 goes out to the network even if GHC 8.8.4 is already downloaded by ghcup, I guess to inform the user if there's a newer version available. This can cause problems if e.g. you put it in your .profile, or some build script, that should work regardless of network status.

So the feature request here is to add a flag to ghcup to only do what it can do locally and fail otherwise. For example, ghcup --no-network set ghc 8.10.1 would succeed (and not initiate any network connections) if GHC 8.10.1 is already installed, and would fail (and not initiate any network connections!) if GHC 8.10.1 is not yet installed. Similarly, ghcup tui, ghcup rm, ghcup list should all work based on locally available information. Even ghcup install could work if the given GHC version is already downloaded into cache but not installed yet.

The main reason for network connection isn't to download GHC tarballs, but to download metadata information about available versions, their tags etc.: https://gitlab.haskell.org/haskell/ghcup-hs/-/blob/master/ghcup-0.0.5.yaml

This information is used in a number of ways. Whether a version is already installed doesn't really matter for this.

ghcup-0.0.5.yaml is already cached and has an access time timeout of 5 minutes, before another download is attempted.

We could provide a --no-network flag, but it would just have to outright fail if ghcup-0.0.5.yaml doesn't exist.

Another possibility would be to include the state of that file via TH at release time in the binary, so that there's always a fallback, even with no network. But that would make it difficult to fix broken metadata if people overuse the --no-network feature. And from reading this ticket, I think this mechanism isn't particularly clear to users, because it's well hidden.

As a user that knows nothing about the internals of ghcup, I am confused by this comment, not by how --no-network should work :)

I can see how this ghcup-0.0.5.yaml file would be needed to:

• Notify the user of new available GHC versions
• Find what exactly needs to be done to install a given GHC version

But with --no-network I wouldn't expect either of these to happen. It is perfectly understandable that ghcup --no-network set ghc 9.0.1 wouldn't notify me that GHC 9.0.2 is available. And the second case (installing a new GHC version) should just fail with --no-network anyway.

(I should probably also clarify that I don't necessarily expect --no-network to be able to do anything if I haven't run ghcup --network (i.e.ghcup without --no-network) ever before)

As a user that knows nothing about the internals of ghcup, I am confused by this comment, not by how --no-network should work :)

If you do ghcup set ghc latest we need to read the metadata file to figure out which GHC version corresponds to latest tag. If you run ghcup list we need it as well.

There are many reasons we need to read the file. I've done some work to avoid network calls for ghcup whereis: f04708e8

This could be extended to other commands and may require some architectural changes. But I'm not really sure if --no-network is the solution.

I just noticed you can already do what you want:

ghcup -s file:///path/to/ghcup-0.0.5.yaml set ghc 8.10.5

And then it's on you to ensure the file exists. If it doesn't, ghcup will just fail with no network call.

I'm in the process of defining more fine-grained appstate access through LabelOptic. However, even functions like ghcup rm ghc 9.0.1 need network access (or use the cached ghcup-0.0.5.yaml) to display the post-remove messages like: https://gitlab.haskell.org/haskell/ghcup-hs/-/blob/master/ghcup-0.0.5.yaml#L152

A more elaborate interface could be:

1. provide ghcup prefetch subcommand with metadata, ghc, cabal, hls, stack arguments
2. provide --no-network global flag, which a) avoids unnecessary functionality like update check and post-install/remove messages and b) fails if any downloadable and required asset is missing

But is that really worth it?

If that makes things easier, my main angle would be ghcup set. If there was a simple way to run ghcup set without it initiating any network access, I'd be golden. I just thought originally that supporting the other operations in offline mode would come for free.

mentioned in commit 2c7176d9

mentioned in commit 12a047fd

!120 (merged) has an implementation of a --offline switch. I haven't added a prefetch command yet.

Commit: !120 (12a047fd)

added typeimprovement label

changed milestone to %0.1.16

mentioned in commit dd6410a0

mentioned in commit 6ec528c7

mentioned in commit 6143cdf2

prefetch subcommand added as well. If you care, try out the branch: https://gitlab.haskell.org/haskell/ghcup-hs/-/tree/issue-180

Done

closed

OK I've tried out the branch. On this crappy setup that I have no control over, released ghcup set ghc 8.8.4 takes 2m7s, while a local build from issue-180 branch takes 0.012s. What's interesting, is that set is so fast (so seemingly doesn't do any network traffic) even without the --offline flag.

BTW I feel really stupid for the --no-network name instead of --offline in retrospect :D

Thanks for the quick turnaround!