Set the default URL source to the vanilla yaml to ensure we get the latest HLS binaries on time

[wz1000]

See the discussion in haskell/ghcup-metadata#159

[hasufell]

As I designed the interaction with GHCup of this extension, I'm strongly against it.

[wz1000]

I think it is in the interest of both HLS users and developers for the vscode extension to have prompt access to new HLS updates.

[hasufell]

-1

This is unreasonable.

1. end users did not opt into this. You're overwriting user configuration, which is incredibly bad and against everything GHCup stands for.
2. end users may now end up with bindists from different channels, depending on how they invoke ghcup (bad and confusing)
3. large number of vanilla GHC bindists are broken and won't install due to the destdir bug
4. we now have significant regression wrt platform support, especially for cabal and stack binaries
5. The --url-source switch overwrites everything else... so if the user has prereleases channel added, it will be gone

I don't think you really understand the implications of this.

[wz1000]

I would really prefer that the extension keeps using the default yaml file with all , but this is really not viable if there is no timeline for when new HLS versions will be available using that.

The only other alternative I can see is to maintain a seperate ghcup metadata yaml file that follows the default master but adds support for newer HLS versions.

[hasufell]

I would really prefer that the extension keeps using the default yaml file with all

I don't think you are in the position to speak for the GHCup user base, nor make such a decision for them.

The usage of metadata files has been communicated to the community very clearly in my blog post: https://hasufell.github.io/posts/2023-11-14-ghcup-is-not-an-installer.html

Releases historically mostly appeared 1-2 weeks after upstream releases. This will not change.

Users already have all the options they need. Misconfiguring this extension is going to erode trust between GHCup and its end users and I want nothing to do with that.

[michaelpj]

I agree that we shouldn't do this if it's likely to cause problems for users.

[wz1000]

I agree, this is not ideal, but it is also not ideal for releases to be delayed indefinitely and rely on volunteers to prepare binary distributions.

I'm closing this in light of all the problems, but I hope we can find a better solution that works for everyone.