[Discussion] Restore `updateBehavior`?

[hasufell]

@wz1000 and @simonmichael want to be notified before every download with the options:

1. yes
2. no
3. yes, don't ask again
4. no, don't ask again

Option 3. and 4. would be set globally, for all projects.

@hasufell argued that this doesn't have clear semantics and the user should rather be able to freeze (or set) the toolchain configuration per project.

Currently, if a user doesn't want auto-updates, they can either:

• set haskell.manageHLS to PATH and use ghcup tui or...
• set haskell.serverExecutablePath to something interesting

---

Implementation-wise, this would require to manually check whether an update/download would be imminent before running ghcup run --hls <ver> --ghc <ver>, which currently installs the entire toolchain in one go.

[hasufell]

I would propose the following (assuming haskell.manageHLS is set to GHCup):

1. in a new project we install the toolchain without asking for confirmation
2. then we store the toolchain configuration in ExtensionContext.workspaceState, which is basically project-specific state
3. when the project is re-opened, we check the possibly new configuration received by ghcup with the saved state
   • if they differ, we ask for confirmation: 1. yes, 2. no, 3. always, 4. never
   • if 3. or 4. is selected, we store the answer in workspace-specific settings, so it won't show up next time (unless it's a different workspace/project)

Further:

• the toolchain configuration can also be set manually in workspace specific configuration or in global configuration, in which case ghcup will always try to install this and no other (and won't ask)
• re-add updateBehavior setting, which will control whether the popup from point 3. will show up: 1. ask, 2. yes, 3. no
• the format of the toolchain configuration setting would be something like {"haskell.toolchain": [{"tool": "hls", "ver": "1.6.1.0"}, {"tool": "ghc", "ver": "project-ghc"}, {"tool": "cabal", "ver": "latest"}]}
• we could also consider to save both the current and previous toolchain config in ExtensionContext.workspaceState from point 2. and then figure out a way to show a Revert to previous config popup when the server crashes more than 3 times

---

This is not trivial logic, though. But it would allow users to:

1. prevent a possibly breaking update/downgrade
2. roll back to previous configuration
3. explicitly set a configuration in advance

And all that without annoying users about downloads. If you use ghcup, you should expect downloads.

---

Open questions:

• when saving toolchain state, do we pin the GHC version as well or do we set it to project-ghc?
• what is the behavior if you omit a tool from haskell.toolchain array?
• what are the defaults for each popup when it's discarded without a selected answer?

[pepeiborra]

My only concern is that the proposed logic seems quite complex, and risky in terms of edge cases.

But I understand @wz1000 and @simonmichael demand, since Nix and other users do not want to have ghcup manage their Haskell toolchain.

[hasufell]

since Nix and other users do not want to have ghcup manage their Haskell toolchain

There seems to be some confusion here. This discussion is not about whether or not nix users want ghcup to manage their haskell toolchain. That is already optional and off by default.

This is about users who want automatic toolchain management, but intervene in the scenario of updates.

[pepeiborra]

This is about users who want automatic toolchain management, but intervene in the scenario of updates.

Right, so this is only for auto-updates. In that case I am less convinced that the extra complication is worth it. Is there a simpler solution, like not auto-updating at all?

[hasufell]

Is there a simpler solution, like not auto-updating at all?

Well, the problems are:

1. what is an update? This becomes blurry if you're running multiple projects with different toolchain requirements. The only solution to make this semantically predictable is recording the previous configuration, imo. Otherwise, we're creating windows-style UX.
2. not updating at all is weird UX for automatically managed toolchain, because if you change your with-compiler setting in cabal.project or bump your stackage lts, then your project will just fail. At this point, the user probably just wants to disable automatic toolchain management.

Instead of trying to be smart about updates, we can simply keep the current logic, but provide an additional escape hatch from the PATH vs ghcup auto-updates: explicitly setting toolchain configuration for a workspace, such as:

{
  "haskell.toolchain": [
    {
      "tool": "hls",
      "ver": "1.6.1.0"
    },
    {
      "tool": "ghc",
      "ver": "project-ghc"
    },
    {
      "tool": "cabal",
      "ver": "latest"
    }
  ]
}

Now you have 3 main possibilities:

1. { "haskell.manageHLS": "GHCup" }
2. { "haskell.manageHLS": "PATH" }
3. { "haskell.manageHLS": "GHCup" } + an explicit tool version config

So with this you could opt out of updates, but would need to do so yourself. The extension won't provide popups for that. This would be simple to implement and doesn't require additional states or reasoning about edge cases.

And the default is to update HLS automatically, which I believe is what most users will expect (note that automatic update does not mean we update ghc itself randomly, unless a new with-compiler setting is detected or a new stackage lts).

[wz1000]

Right, so this is only for auto-updates. In that case I am less convinced that the extra complication is worth it. Is there a simpler solution, like not auto-updating at all?

For the record, I would be satisfied by a simple prompt that asks for consent before downloading or installing anything to the users machine, like this little bit of code in clangd: https://github.com/clangd/vscode-clangd/blob/f283f80907a37b28103e7aa43fe58654f0d68269/src/install.ts#L99

[simonmichael]

@wz1000 and @simonmichael want ...

@wz1000 and @simonmichael demand ...

I know you're using shorthand, but I'd prefer not to be characterised/(mis)quoted this way. We had a complex chat about a complex topic with plenty of misunderstanding, and I can't spend the time to keep clarifying my positions here.
[Polite request here, can't seem to find the right wording.. thanks. :)]

[hasufell]

@wz1000 and @simonmichael want ...

@wz1000 and @simonmichael demand ...

I know you're using shorthand, but I'd prefer not to be characterised/(mis)quoted this way. We had a complex chat about a complex topic with plenty of misunderstanding, and I can't spend the time to keep clarifying my positions here. [Polite request here, can't seem to find the right wording.. thanks. :)]

Sorry, I don't understand. What are you requesting?

[hasufell]

Lets look at it from another perspective: cabal-install. It doesn't ask you whether you want to update either. If you change your project configuration, the resolver might pick newer versions (even if you didn't run cabal update). The only way to force it not to update is to freeze the resolution.

So for cabal:

1. global input: package index
2. local input: project config
3. resolver: cabal
4. output: new dependency configuration

For VSCode:

1. global input: ghcup-metadata (both ghcup-0.0.7.yaml and hls-metadata-0.0.1.json)
2. local input: project config (e.g. with-compiler or stackage LTS)
3. resolver
   • getHLSesfromMetadata and getHLSesFromGHCup functions do it for HLS
   • for GHC we run haskell-language-server-wrapper --project-ghc-version
4. output: toolchain configuration

---

Now the main difference is that we don't have an equivalent of cabal update. It is done implicitly (as is the case for cargo).