Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support aliases in 'config add-release-channel' and '--url-source' #1155

Merged
merged 5 commits into from
Dec 30, 2024

Conversation

dfordivam
Copy link
Collaborator

@dfordivam dfordivam commented Nov 15, 2024

Add the URIs of known release channels in code, and allow choosing them via aliases.

Ref: #1050

With this its possible to just do 🙃
ghcup -s vanilla install ghc 9.8.3

Comment on lines 398 to 401
data ChannelAlias = MainChannel
| CrossChannel
| PrereleasesChannel
| VanillaChannel
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is now a bit confusing, because the config supports the value GHCupURL and StackSetupURL, but none of the other channels.

# Where to get GHC/cabal/hls download info/versions from. This is a list that performs
# union over tool versions, preferring the later entries.
url-source:
## Use the internal download uri, this is the default
- GHCupURL
## Prefer stack supplied metadata (will still use GHCup metadata for versions not existing in stack metadata)
# - StackSetupURL
## Add pre-release channel
# - https://raw.githubusercontent.com/haskell/ghcup-metadata/master/ghcup-prereleases-0.0.7.yaml
## Add nightly channel
# - https://ghc.gitlab.haskell.org/ghcup-metadata/ghcup-nightlies-0.0.7.yaml
## Add cross compiler channel
# - https://raw.githubusercontent.com/haskell/ghcup-metadata/master/ghcup-cross-0.0.8.yaml
## Use dwarf bindist for 9.4.7 for ghcup metadata
# - ghcup-info:
# ghcupDownloads:
# GHC:
# 9.4.7:
# viTags: []
# viArch:
# A_64:
# Linux_UnknownLinux:
# unknown_versioning:
# dlUri: https://downloads.haskell.org/ghc/9.4.7/ghc-9.4.7-x86_64-deb10-linux-dwarf.tar.xz
# dlSubdir:
# RegexDir: "ghc-.*"
# dlHash: b261b3438ba455e3cf757f9c8dc3a06fdc061ea8ec287a65b7809e25fe18bad4
## for stack metadata and the linux64-tinfo6 bindists, use static alpine for 9.8.1
# - setup-info:
# ghc:
# linux64-tinfo6:
# 9.8.1:
# url: "https://downloads.haskell.org/~ghc/9.8.1/ghc-9.8.1-x86_64-alpine3_12-linux-static.tar.xz"
# content-length: 229037440
# sha256: b48f3d3a508d0c140d1c801e04afc65e80c0d25e7e939a8a41edb387b26b81b3

ghcup-hs/lib/GHCup/Types.hs

Lines 388 to 393 in a32a559

data NewURLSource = NewGHCupURL
| NewStackSetupURL
| NewGHCupInfo GHCupInfo
| NewSetupInfo SetupInfo
| NewURI URI
deriving (Eq, GHC.Generic, Show)

And the json instances are finicky.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see alias mainly as a convenience for CLI use. And perhaps primarily for ghcup -s <channel> where the expectation is not to even modify the config. As I would expect most users not wanting to add channel in config just for a one off use case.

The GHCupURL is identical to "main", and StackSetupURL has its own purpose.

If we add support of channel alias in config.yaml, then it will be a bigger change, and it will come with the costs of backward compatibility etc.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It creates inconsistency, because NewURLSource is valid in both the config and in the cli: ghcup -s GHCupURL tui.

Now we have another set of aliases that don't work in the config but in the cli. I have tried to keep both of them in sync as much as possible.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, so adding support of channel alias in config.yaml is better?
I can see one case where it would be helpful, on metadata bump users won't need to modify config if they have channel alias in it.

should the JSON accept the string as it is "prerelease" / "vanilla". or is there any need to make it "prerelease-channel", "vanilla-channel", or something else.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now the alias is part of URLSource & NewURLSource

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correction alias is only part of NewURLSource


# add a release channel
ghcup config add-release-channel vanilla|]
Copy link
Member

@hasufell hasufell Dec 21, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Vanilla isn't a good example, because we usually want to set it instead of adding it.

So I think we want two examples:

  • adding prereleases
  • setting vanilla (discrding everything else)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

@@ -379,6 +379,7 @@ instance Pretty TarDir where
-- | Where to fetch GHCupDownloads from.
data URLSource = GHCupURL
| StackSetupURL
| ChannelAlias ChannelAlias
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't want to touch URLSource. It's there for backwards comp and already supports NewURLSource through the SimpleList constructor.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, fixed

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm, the ghcup -s vanilla install ghc 9.8.3 no longer works without URLSource. I should probably convert optUrlSource :: Maybe URLSource to optUrlSource :: Maybe NewURLSource

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I should probably convert optUrlSource :: Maybe URLSource to optUrlSource :: Maybe NewURLSource

That sounds like a breaking change, no?

Did you check parseUrlSource in GHCup.Utils.Parsers?

Copy link
Collaborator Author

@dfordivam dfordivam Dec 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did this in backward compatible way, by modifying parseUrlSource too. It now handles both URLSource and NewURLSource

Both of these work

cabal run exe:ghcup -- -s "{\"OwnSource\": "\"https://raw.githubusercontent.com/haskell/ghcup-metadata/master/ghcup-prereleases-0.0.8.yaml\""}" list

cabal run exe:ghcup -- -s vanilla install ghc 8.10.2

@hasufell hasufell merged commit 389c36d into master Dec 30, 2024
60 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants