-
Notifications
You must be signed in to change notification settings - Fork 92
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
Conversation
lib/GHCup/Types.hs
Outdated
data ChannelAlias = MainChannel | ||
| CrossChannel | ||
| PrereleasesChannel | ||
| VanillaChannel |
There was a problem hiding this comment.
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.
Lines 54 to 92 in a32a559
# 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 |
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
e47d084
to
522ce7b
Compare
lib-opt/GHCup/OptParse/Config.hs
Outdated
|
||
# add a release channel | ||
ghcup config add-release-channel vanilla|] |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
lib/GHCup/Types.hs
Outdated
@@ -379,6 +379,7 @@ instance Pretty TarDir where | |||
-- | Where to fetch GHCupDownloads from. | |||
data URLSource = GHCupURL | |||
| StackSetupURL | |||
| ChannelAlias ChannelAlias |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, fixed
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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
522ce7b
to
58a98b1
Compare
…urce' Add the URIs of known release channels in code, and allow choosing them via aliases.
While still maintaining backward compatibility with URLSource
80f41ab
to
a68ba98
Compare
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