Current master fails to reach over the network...
Environment
MacoS Catalina and Linux CentOS 8. Cabal-3.2.0.0, ghc-8.8.3. Current master of this repo.
$ ~/.ghcup/bin/ghcup debug-info
DebugInfo {diBaseDir = "/Users/ur20980/.ghcup", diBinDir = "/Users/ur20980/.ghcup/bin", diGHCDir = "/Users/ur20980/.ghcup/ghc", diCacheDir = "/Users/ur20980/.ghcup/cache", diArch = A_64, diPlatform = PlatformResult {_platform = Darwin, _distroVersion = Just (General (Version {_vEpoch = Nothing, _vChunks = [[Digits 10],[Digits 15]], _vRel = []}))}}
$ ~/.ghcup/bin/ghcup numeric-version
0.1.4$
$Problem
On all of my platforms, ghcup built from the master completely fails on the network access:
$ ~/.cabal/bin/ghcup -v debug-info
[ Debug ] Receiving download info from: GHCupURL
[ Debug ] Unable to get/parse Last-Modified header
ghcup: SSL_connect: resource vanished (Connection reset by peer)
$ I thought we already talked about the [un]reasonable-ness of the need to reach over the Internet to answer simple questions, like "what my config is?", "what kind of system am I running on?", and "what is my version?"
Since there's no more of debugging output, the above is all I can tell you.
The binary provided via $ ghcup upgrade seems functional, the binary built from the current master is not.
Activity
I thought we already talked about the [un]reasonable-ness of the need to reach over the Internet to answer simple questions, like "what my config is?", "what kind of system am I running on?", and "what is my version?"
debug-infois currently still a command (unlike--versionand--numeric-version). Before any command runs, ghcup checks for a new version. I find this reasonable.I'm in the process of improving that side, as in:
- if it cannot fetch the download info, emit a warning, then:
- try to fall back to the cached version in ~/.ghcup/cache/foo.json
- allow to run commands that don't need it
If you want that to be improved quicker, provide a pull request. I'm the only maintainer of this project. And all these things are already on my TODO.
On all of my platforms,
ghcupbuilt from the master completely fails on the network access:I didn't mention this in the last issue, but there are two ways to build ghcup:
- with curl, which is what all shipped binaries do (run:
cabal build -fcurl) - with the internal downloader, which is very custom and links to OpenSSL. This one has had other problems, which is why the shipped binaries don't use it right now.
Try with
-fcurland report back.- if it cannot fetch the download info, emit a warning, then:
debug-infois currently still a command (unlike--versionand--numeric-version). Before any command runs, ghcup checks for a new version. I find this reasonable.I don't, given the result. Recommendation:
- do that check only for some of the commands;
- make that check a part of
upgradecommand only; - make
debug-infolike--version
I'm in the process of improving that side...
Yes, that would be much better. BTW, for this plan to work, I expect
~/.ghcup/cache/foo.jsonto be included in the distribution, to avoid the chicken-and-egg problem (in order to "fall back" there had to be at least one successful run before that, which successfully fetched the file and cached it).I didn't mention this in the last issue, but there are two ways to build ghcup:
- with curl, which is what all shipped binaries do (run:
cabal build -fcurl) - with the internal downloader, which is very custom and links to OpenSSL. This one has had other problems, which is why the shipped binaries don't use it right now.
Try with
-fcurland report back.Let me begin with expressing my strong dislike for (2), because of how it (doesn't) handle web proxies.
With
-fcurlit builds, installs, and fails on attempt to fetchghcup-0.0.2.json, which apparently doesn't exist? Trying to cut-and-paste the URL in question to "direct"curl:[ur20980@g53 ghcup-hs]$ ghcup debug-info [ Error ] Error fetching download info: DownloadFailed (NonZeroExit 22 "curl" ["-sSfL","https://www.haskell.org/ghcup/data/ghcup-0.0.2.json"]) [ur20980@g53 ghcup-hs]$ curl -sSfL -k https://www.haskell.org/ghcup/data/ghcup-0.0.2.json curl: (22) The requested URL returned error: 500 [ur20980@g53 ghcup-hs]$ curl -sSfL -k https://www.haskell.org/ghcup/data/ghcup-0.0.1.json {"toolRequirements":{"GHC":{"unknown_version":{"Linux_Ubuntu":{"unknown_versioning":{"distroPKGs":["build-essential","curl","libgmp-dev","libffi-dev","libncurses-dev","libtinfo5"],"notes":""}},"Linux_Alpine":{"unknown_versioning": . . . . .Edited by Mouse-
- do that check only for some of the commands;
That's what I said.
- make that check a part of
upgradecommand only;
No. We want that for list and everything else as well. Users should be annoyed for not upgrading.
- make
debug-infolike--version
That's possible with some adjustment. Please provide a PR.
Yes, that would be much better. BTW, for this plan to work, I expect
~/.ghcup/cache/foo.jsonto be included in the distribution, to avoid the chicken-and-egg problem (in order to "fall back" there had to be at least one successful run before that, which successfully fetched the file and cached it).That should already be the case when you ran the bootstrap script and when it did its job successfully. If the bootstrap script fails to download anything, then your configuration is likely broken.
With
-fcurlit builds, installs, and fails on attempt to fetchghcup-0.0.2.json, which apparently doesn't exist? Trying to cut-and-paste the URL in question to "direct"curl:Yes, because this is a development version and not released. Use the local version included in the git repository
ghcup --url-source file://<path-to-ghcup-0.0.2.json> --cache list Users should be annoyed for not upgrading
We differ on this. Given my experience with the recent upgrades, I think my position is understandable.
Please provide a PR...
If I knew Haskell well enough to do that, rest assured it would've been done a while ago.
I expect
~/.ghcup/cache/foo.jsonto be included in the distributionThat should already be the case when you ran the bootstrap script and when it did its job successfully
OK, that takes care of it.
With
-fcurlit builds, installs...... use the local version ...
--url-source ...The
--url-sourceworks. It would be nice if this flag (and--cache- BTW, what exactly does it do?) were included in the--helpoutput.I'd like to ask to make this config the default. I.e., have the default build with
curl, and build with the internal downloader (which does not work) only if something like-fno-curlis specified.P.S. When do you think
ghcup-0.0.2.jsonwould end up on the main web site, obviating the need to specify--url-source ...flag?Edited by Mouse-
We differ on this. Given my experience with the recent upgrades, I think my position is understandable.
I cannot follow.
The
--url-sourceworks. It would be nice if this flag (and--cache- BTW, what exactly does it do?) were included in the--helpoutput.--cache is already in the help output:
-c,--cache Cache downloads in ~/.ghcup/cache--url-sourceis undocumented, because it's a developer feature.I'd like to ask to make this config the default. I.e., have the default build with
curl, and build with the internal downloader (which does not work) only if something like-fno-curlis specified.I thought about it. I also thought about making a switch
--downloader=<internal|wget|curl>, but I'm not sure yet.P.S. When do you think
ghcup-0.0.2.jsonwould end up on the main web site, obviating the need to specify--url-source ...flag?I can upload it, but it isn't meant to be uploaded before the next release. I don't get paid to do ghcup and depending on tomorrow, I might be gone for a couple of weeks. So I can't say when the next release will be. The cross branch is almost done. But testing it is cumbersome, because of the GHC compile times.
If you care, check out the
crossbranch of this repo, it also contains a lot of bugfixes. --url-sourceis undocumented, because it's a developer feature.I'm not a developer (of this package at least), yet it turned out that I had to use it. I think it's worth documenting.
I thought about it. I also thought about making a switch --downloader=<internal|wget|curl>, but I'm not sure yet.
I like this. Then, regardless of what default the binary has been built with, the user could alias invocation to, e.g.,
ghcup --downloader=wget, and things would work automatically from that point on.Unless it's much simpler/quicker for you to just change the default build for the binary? Not as nice architecturally, but maybe easier for you in the short term.
can upload
ghcup-0.0.2.json, but it isn't meant to be uploaded before the next release...Understood. Still, could you please upload it?
If you care, check out the
crossbranch of this repo, it also contains a lot of bugfixes.If that's your recommendation... I can't be considered a Haskell developer because of lack of experience and expertise - but I've enough computing resources to run compiles.
Re. Tomorrow - I hope things will turn out the way you'd like them to.
Edited by Mouse-
Unless it's much simpler/quicker for you to just change the default build for the binary? Not as nice architecturally, but maybe easier for you in the short term.
It'll still be ugly, because I need to CPP-ifdef a lot. The internal downloader must be optional at compile-time for a simple reason: it causes linking to OpenSSL. All linux binaries are statically linked. OpenSSL also isn't particularly ABI compatible across, say, FreeBSD releases. So it's just not that portable.
I still think the cabal way might be the sanest: if curl exists, use that, otherwise, try wget. I can't think of a case where a user has both curl and wget installed, but only wget succeeds with the download?
Understood. Still, could you please upload it?
Yes, I uploaded it
I'd that's your recommendation... I can't be considered a Haskell developer because of lack of experience and expertise - but I've enough computing resources to run compiles.
I just need to manage to compile GHC once for cross-compiling to test some stuff, then I am almost done.
Re. Tomorrow - I hope things will turn out the way you'd like them to.
Thanks.
I still think the cabal way might be the sanest: if curl exists, use that, otherwise, try wget...
If you replace "exists" with "succeeds" - I'd agree. With this approach you can probably cycle through all the three if you wish.
I can't think of a case where a user has both curl and wget installed, but only wget succeeds with the download?
I can. One of my office machines is like that. Also, it could be the matter of passing the right (for the user's specific environment) flags to the program you're invoking. Like, some
curlinstallations would require-k, but that's not something desirable in general...Yes, I uploaded
ghcup-0.0.2.jsonThank you!
Edited by Mouse-
I can. One of my office machines is like that. Also, it could be the matter of passing the right (for the user's specific environment) flags to the program you're invoking. Like, some
curlinstallations would require-k, but that's not something desirable in general...My distro solves this by allowing an environmet variable
EXTRA_CURLor something, same for wget. So you don't control the entire invocation, but you can pass additional arguments. If you pass bad arguments, it's on you... I'll think about it. you don't control the entire invocation, but you can pass additional arguments
That should work, assuming the arguments that are passed by default (aka "enforced") would not conflict...
Would you consider a complete replacement of arguments that are passed during the invocation? Via something like
GHCUP_CURL_ARGSenv var?Update
On one machine (Mac)
crossbranch built and installed fine, and seems to work fine:$ ghcup list Tool Version Tags Notes ✗ ghc 7.10.3 base-4.8.2.0 ✗ ghc 8.0.2 base-4.9.1.0 . . . . . ✔✔ ghc 8.8.3 recommended,base-4.13.0.0 ✓ ghc 8.10.1 latest,base-4.14.0.0 ✗ cabal 2.4.1.0 ✗ cabal 3.0.0.0 ✔✔ cabal 3.2.0.0 latest,recommended ✔✔ ghcup 0.1.4 latest,recommended $ type ghcup ghcup is hashed (/Users/ur20980/.cabal/bin/ghcup) $ git branch * cross master $On CentOS 8 Linux, it installs OK, but fails to run correctly:
[ur20980@g53 ghcup-hs]$ git branch * cross master [ur20980@g53 ghcup-hs]$ type ghcup ghcup is hashed (/home/ur20980/.cabal/bin/ghcup) [ur20980@g53 ghcup-hs]$ ghcup list ghcup: ParseErrorBundle {bundleErrors = TrivialError 25 (Just (Tokens ('-' :| ""))) (fromList [EndOfInput]) :| [], bundlePosState = PosState {pstateInput = "../ghc/8.8.3/bin/ghc-8.8.3", pstateOffset = 0, pstateSourcePos = SourcePos {sourceName = "", sourceLine = Pos 1, sourceColumn = Pos 1}, pstateTabWidth = Pos 8, pstateLinePrefix = ""}} [ur20980@g53 ghcup-hs]$Same branch and pulls from the repo, same version of GHC and Cabal (of course, different binaries - between Mac and Linux)...
Update 2
In case it matters: building the current
masterbranch on the Linux machine above resulted in a working (dynamic, if you care to know ;) binary:$ ghcup list [ Warn ] New GHC version available: 8.10.1. To upgrade, run 'ghcup install 8.10.1' Tool Version Tags Notes ✗ ghc 7.10.3 base-4.8.2.0 ✗ ghc 8.0.2 base-4.9.1.0 ✗ ghc 8.2.2 base-4.10.1.0 ✗ ghc 8.4.1 base-4.11.0.0 ✗ ghc 8.4.2 base-4.11.1.0 ✗ ghc 8.4.3 base-4.11.1.0 ✗ ghc 8.4.4 base-4.11.1.0 ✗ ghc 8.6.1 base-4.12.0.0 ✗ ghc 8.6.2 base-4.12.0.0 ✗ ghc 8.6.3 base-4.12.0.0 ✗ ghc 8.6.4 base-4.12.0.0 ✓ ghc 8.6.5 base-4.12.0.0 ✗ ghc 8.8.1 base-4.13.0.0 ✗ ghc 8.8.2 base-4.13.0.0 ✔✔ ghc 8.8.3 recommended,base-4.13.0.0 ✗ ghc 8.10.1 latest,base-4.14.0.0 ✗ cabal 2.4.1.0 ✗ cabal 3.0.0.0 ✔✔ cabal 3.2.0.0 latest,recommended ✔✔ ghcup 0.1.4 latest,recommended $ ghcup install 8.10.1 [ Warn ] New GHC version available: 8.10.1. To upgrade, run 'ghcup install 8.10.1' [ Info ] downloading: https://downloads.haskell.org/~ghc/8.10.1/ghc-8.10.1-x86_64-centos7-linux.tar.xz % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 191M 100 191M 0 0 38.5M 0 0:00:04 0:00:04 --:--:-- 39.0M [ Info ] verifying digest of: ghc-8.10.1-x86_64-centos7-linux.tar.xz [ Info ] Unpacking: ghc-8.10.1-x86_64-centos7-linux.tar.xz to /tmp/ghcup-JaVDX8 [ Info ] Installing GHC (this may take a while) [ ghc-make ] /usr/bin/install -c -m 755 -d "/home/ur20980/.ghcup/ghc/8.10.1/lib/ghc-8.10.1/bin" [ Info ] GHC installation successful $Edited by Mouse-
On CentOS 8 Linux, it installs OK, but fails to run correctly:
Wow, that is interesting. I'll have to test that in a docker image. The parser should behave exactly the same on all platforms.
Can you run
ghcup --versionon the Centos one?EDIT: so I tried this in a fresh centos docker container. I cannot reproduce with the binaries from the latest pre-release tag: https://downloads.haskell.org/~ghcup/0.1.5_alpha1/
Edited by Julian Ospald Wow, that is interesting
Producing interesting cases is my specialty. ;-)
Can you run
ghcup --versionon the Centos one?$ ghcup --version The GHCup Haskell installer, version 0.1.4 $ type ghcup ghcup is hashed (/home/ur20980/.cabal/bin/ghcup)So, this is unquestionably the binary that I built from source via Cabal, from the master branch. Why it doesn't say something like
version 0.1.5_alpha, I don't know.And as I said - master branch seems to function fine on CentOS 8.
-
Can you try https://downloads.haskell.org/~ghcup/0.1.5_alpha1/x86_64-linux-ghcup-0.1.5_alpha1 on Centos8? I might have pushed some fixes in-between or something.
The GHCup Haskell installer, version 0.1.4If you built from source, this should be something like
The GHCup Haskell installer, version v0.1.4-36-ge54a216. So if the git tag is missing, this might not be the version built from git.Edited by Julian Ospald $ ll x86_64-linux-ghcup-0.1.5_alpha1 -rw-r--r--. 1 ur20980 10775696 Apr 27 10:10 x86_64-linux-ghcup-0.1.5_alpha1 $ chmod a+x !!:$ chmod a+x x86_64-linux-ghcup-0.1.5_alpha1 $ ./x86_64-linux-ghcup-0.1.5_alpha1 --version The GHCup Haskell installer, version 0.1.4 $ ./x86_64-linux-ghcup-0.1.5_alpha1 list --cache x86_64-linux-ghcup-0.1.5_alpha1: ParseErrorBundle {bundleErrors = TrivialError 25 (Just (Tokens ('-' :| ""))) (fromList [EndOfInput]) :| [], bundlePosState = PosState {pstateInput = "../ghc/8.8.3/bin/ghc-8.8.3", pstateOffset = 0, pstateSourcePos = SourcePos {sourceName = "", sourceLine = Pos 1, sourceColumn = Pos 1}, pstateTabWidth = Pos 8, pstateLinePrefix = ""}} $ ./x86_64-linux-ghcup-0.1.5_alpha1 debug-info x86_64-linux-ghcup-0.1.5_alpha1: ParseErrorBundle {bundleErrors = TrivialError 25 (Just (Tokens ('-' :| ""))) (fromList [EndOfInput]) :| [], bundlePosState = PosState {pstateInput = "../ghc/8.8.3/bin/ghc-8.8.3", pstateOffset = 0, pstateSourcePos = SourcePos {sourceName = "", sourceLine = Pos 1, sourceColumn = Pos 1}, pstateTabWidth = Pos 8, pstateLinePrefix = ""}}On the other hand, the one I built from master:
$ ~/.cabal/bin/ghcup list --cache Tool Version Tags Notes ✗ ghc 7.10.3 base-4.8.2.0 ✗ ghc 8.0.2 base-4.9.1.0 ✗ ghc 8.2.2 base-4.10.1.0 ✗ ghc 8.4.1 base-4.11.0.0 ✗ ghc 8.4.2 base-4.11.1.0 ✗ ghc 8.4.3 base-4.11.1.0 ✗ ghc 8.4.4 base-4.11.1.0 ✗ ghc 8.6.1 base-4.12.0.0 ✗ ghc 8.6.2 base-4.12.0.0 ✗ ghc 8.6.3 base-4.12.0.0 ✗ ghc 8.6.4 base-4.12.0.0 ✓ ghc 8.6.5 base-4.12.0.0 ✗ ghc 8.8.1 base-4.13.0.0 ✗ ghc 8.8.2 base-4.13.0.0 ✔✔ ghc 8.8.3 recommended,base-4.13.0.0 ✓ ghc 8.10.1 latest,base-4.14.0.0 ✗ cabal 2.4.1.0 ✗ cabal 3.0.0.0 ✔✔ cabal 3.2.0.0 latest,recommended ✔✔ ghcup 0.1.4 latest,recommendedCan you post the output of
find ~/.ghcupon the Centos one?Are you sure you want exactly that???
$ find ~/.ghcup | wc -l 25308 $ ll ~/.ghcup total 12 drwxr-xr-x. 6 ur20980 77 Apr 15 21:47 ./ drwxr-xr-x. 30 ur20980 4096 Apr 27 09:19 ../ drwxr-xr-x. 2 ur20980 4096 Apr 26 19:11 bin/ drwxr-xr-x. 2 ur20980 135 Apr 25 12:23 cache/ -rw-r--r--. 1 ur20980 84 Mar 15 09:34 env drwxr-xr-x. 5 ur20980 46 Apr 26 19:09 ghc/ drwxr-xr-x. 2 ur20980 68 Apr 27 10:29 logs/ lrwxrwxrwx. 1 ur20980 15 Mar 15 09:47 share -> ghc/8.8.3/share/ $ ll ~/.ghcup/bin total 49524 drwxr-xr-x. 2 ur20980 4096 Apr 26 19:11 ./ drwxr-xr-x. 6 ur20980 77 Apr 15 21:47 ../ -rwxr-xr-x. 1 ur20980 32865168 Apr 16 09:46 cabal* lrwxrwxrwx. 1 ur20980 26 Mar 15 09:47 ghc -> ../ghc/8.8.3/bin/ghc-8.8.3* lrwxrwxrwx. 1 ur20980 21 Apr 26 19:11 ghc-8.10 -> ../ghc/8.10.1/bin/ghc* lrwxrwxrwx. 1 ur20980 21 Apr 26 19:11 ghc-8.10.1 -> ../ghc/8.10.1/bin/ghc* lrwxrwxrwx. 1 ur20980 26 Mar 15 09:36 ghc-8.6 -> ../ghc/8.6.5/bin/ghc-8.6.5* lrwxrwxrwx. 1 ur20980 26 Mar 15 09:36 ghc-8.6.5 -> ../ghc/8.6.5/bin/ghc-8.6.5* lrwxrwxrwx. 1 ur20980 26 Mar 15 09:46 ghc-8.8 -> ../ghc/8.8.3/bin/ghc-8.8.3* lrwxrwxrwx. 1 ur20980 26 Mar 15 09:46 ghc-8.8.3 -> ../ghc/8.8.3/bin/ghc-8.8.3* lrwxrwxrwx. 1 ur20980 27 Mar 15 09:47 ghci -> ../ghc/8.8.3/bin/ghci-8.8.3* lrwxrwxrwx. 1 ur20980 22 Apr 26 19:11 ghci-8.10 -> ../ghc/8.10.1/bin/ghci* lrwxrwxrwx. 1 ur20980 22 Apr 26 19:11 ghci-8.10.1 -> ../ghc/8.10.1/bin/ghci* lrwxrwxrwx. 1 ur20980 27 Mar 15 09:36 ghci-8.6 -> ../ghc/8.6.5/bin/ghci-8.6.5* lrwxrwxrwx. 1 ur20980 27 Mar 15 09:36 ghci-8.6.5 -> ../ghc/8.6.5/bin/ghci-8.6.5* lrwxrwxrwx. 1 ur20980 27 Mar 15 09:46 ghci-8.8 -> ../ghc/8.8.3/bin/ghci-8.8.3* lrwxrwxrwx. 1 ur20980 27 Mar 15 09:46 ghci-8.8.3 -> ../ghc/8.8.3/bin/ghci-8.8.3* lrwxrwxrwx. 1 ur20980 30 Mar 15 09:47 ghc-pkg -> ../ghc/8.8.3/bin/ghc-pkg-8.8.3* lrwxrwxrwx. 1 ur20980 25 Apr 26 19:11 ghc-pkg-8.10 -> ../ghc/8.10.1/bin/ghc-pkg* lrwxrwxrwx. 1 ur20980 25 Apr 26 19:11 ghc-pkg-8.10.1 -> ../ghc/8.10.1/bin/ghc-pkg* lrwxrwxrwx. 1 ur20980 30 Mar 15 09:36 ghc-pkg-8.6 -> ../ghc/8.6.5/bin/ghc-pkg-8.6.5* lrwxrwxrwx. 1 ur20980 30 Mar 15 09:36 ghc-pkg-8.6.5 -> ../ghc/8.6.5/bin/ghc-pkg-8.6.5* lrwxrwxrwx. 1 ur20980 30 Mar 15 09:46 ghc-pkg-8.8 -> ../ghc/8.8.3/bin/ghc-pkg-8.8.3* lrwxrwxrwx. 1 ur20980 30 Mar 15 09:46 ghc-pkg-8.8.3 -> ../ghc/8.8.3/bin/ghc-pkg-8.8.3* -rwxr-xr-x. 1 ur20980 8919264 Apr 16 09:45 ghcup* lrwxrwxrwx. 1 ur20980 11 Mar 15 09:47 haddock -> haddock-ghc* lrwxrwxrwx. 1 ur20980 25 Apr 26 19:11 haddock-8.10 -> ../ghc/8.10.1/bin/haddock* lrwxrwxrwx. 1 ur20980 25 Apr 26 19:11 haddock-8.10.1 -> ../ghc/8.10.1/bin/haddock* lrwxrwxrwx. 1 ur20980 15 Mar 15 09:36 haddock-8.6 -> haddock-ghc-8.6* lrwxrwxrwx. 1 ur20980 24 Mar 15 09:36 haddock-8.6.5 -> ../ghc/8.6.5/bin/haddock* lrwxrwxrwx. 1 ur20980 15 Mar 15 09:46 haddock-8.8 -> haddock-ghc-8.8* lrwxrwxrwx. 1 ur20980 24 Mar 15 09:46 haddock-8.8.3 -> ../ghc/8.8.3/bin/haddock* lrwxrwxrwx. 1 ur20980 34 Mar 15 09:47 haddock-ghc -> ../ghc/8.8.3/bin/haddock-ghc-8.8.3* lrwxrwxrwx. 1 ur20980 34 Mar 15 09:36 haddock-ghc-8.6 -> ../ghc/8.6.5/bin/haddock-ghc-8.6.5* lrwxrwxrwx. 1 ur20980 34 Mar 15 09:36 haddock-ghc-8.6.5 -> ../ghc/8.6.5/bin/haddock-ghc-8.6.5* lrwxrwxrwx. 1 ur20980 34 Mar 15 09:46 haddock-ghc-8.8 -> ../ghc/8.8.3/bin/haddock-ghc-8.8.3* lrwxrwxrwx. 1 ur20980 34 Mar 15 09:46 haddock-ghc-8.8.3 -> ../ghc/8.8.3/bin/haddock-ghc-8.8.3* lrwxrwxrwx. 1 ur20980 11 Mar 15 09:47 hp2ps -> hp2ps-8.8.3* lrwxrwxrwx. 1 ur20980 23 Apr 26 19:11 hp2ps-8.10 -> ../ghc/8.10.1/bin/hp2ps* lrwxrwxrwx. 1 ur20980 23 Apr 26 19:11 hp2ps-8.10.1 -> ../ghc/8.10.1/bin/hp2ps* lrwxrwxrwx. 1 ur20980 11 Mar 15 09:36 hp2ps-8.6 -> hp2ps-8.6.5* lrwxrwxrwx. 1 ur20980 22 Mar 15 09:36 hp2ps-8.6.5 -> ../ghc/8.6.5/bin/hp2ps* lrwxrwxrwx. 1 ur20980 11 Mar 15 09:46 hp2ps-8.8 -> hp2ps-8.8.3* lrwxrwxrwx. 1 ur20980 22 Mar 15 09:46 hp2ps-8.8.3 -> ../ghc/8.8.3/bin/hp2ps* lrwxrwxrwx. 1 ur20980 9 Mar 15 09:47 hpc -> hpc-8.8.3* lrwxrwxrwx. 1 ur20980 21 Apr 26 19:11 hpc-8.10 -> ../ghc/8.10.1/bin/hpc* lrwxrwxrwx. 1 ur20980 21 Apr 26 19:11 hpc-8.10.1 -> ../ghc/8.10.1/bin/hpc* lrwxrwxrwx. 1 ur20980 9 Mar 15 09:36 hpc-8.6 -> hpc-8.6.5* lrwxrwxrwx. 1 ur20980 20 Mar 15 09:36 hpc-8.6.5 -> ../ghc/8.6.5/bin/hpc* lrwxrwxrwx. 1 ur20980 9 Mar 15 09:46 hpc-8.8 -> hpc-8.8.3* lrwxrwxrwx. 1 ur20980 20 Mar 15 09:46 hpc-8.8.3 -> ../ghc/8.8.3/bin/hpc* lrwxrwxrwx. 1 ur20980 12 Mar 15 09:47 hsc2hs -> hsc2hs-8.8.3* lrwxrwxrwx. 1 ur20980 24 Apr 26 19:11 hsc2hs-8.10 -> ../ghc/8.10.1/bin/hsc2hs* lrwxrwxrwx. 1 ur20980 24 Apr 26 19:11 hsc2hs-8.10.1 -> ../ghc/8.10.1/bin/hsc2hs* lrwxrwxrwx. 1 ur20980 12 Mar 15 09:36 hsc2hs-8.6 -> hsc2hs-8.6.5* lrwxrwxrwx. 1 ur20980 23 Mar 15 09:36 hsc2hs-8.6.5 -> ../ghc/8.6.5/bin/hsc2hs* lrwxrwxrwx. 1 ur20980 12 Mar 15 09:46 hsc2hs-8.8 -> hsc2hs-8.8.3* lrwxrwxrwx. 1 ur20980 23 Mar 15 09:46 hsc2hs-8.8.3 -> ../ghc/8.8.3/bin/hsc2hs* lrwxrwxrwx. 1 ur20980 29 Mar 15 09:47 runghc -> ../ghc/8.8.3/bin/runghc-8.8.3* lrwxrwxrwx. 1 ur20980 24 Apr 26 19:11 runghc-8.10 -> ../ghc/8.10.1/bin/runghc* lrwxrwxrwx. 1 ur20980 24 Apr 26 19:11 runghc-8.10.1 -> ../ghc/8.10.1/bin/runghc* lrwxrwxrwx. 1 ur20980 29 Mar 15 09:36 runghc-8.6 -> ../ghc/8.6.5/bin/runghc-8.6.5* lrwxrwxrwx. 1 ur20980 29 Mar 15 09:36 runghc-8.6.5 -> ../ghc/8.6.5/bin/runghc-8.6.5* lrwxrwxrwx. 1 ur20980 29 Mar 15 09:46 runghc-8.8 -> ../ghc/8.8.3/bin/runghc-8.8.3* lrwxrwxrwx. 1 ur20980 29 Mar 15 09:46 runghc-8.8.3 -> ../ghc/8.8.3/bin/runghc-8.8.3* lrwxrwxrwx. 1 ur20980 6 Mar 15 09:47 runhaskell -> runghc* lrwxrwxrwx. 1 ur20980 28 Apr 26 19:11 runhaskell-8.10 -> ../ghc/8.10.1/bin/runhaskell* lrwxrwxrwx. 1 ur20980 28 Apr 26 19:11 runhaskell-8.10.1 -> ../ghc/8.10.1/bin/runhaskell* lrwxrwxrwx. 1 ur20980 10 Mar 15 09:36 runhaskell-8.6 -> runghc-8.6* lrwxrwxrwx. 1 ur20980 27 Mar 15 09:36 runhaskell-8.6.5 -> ../ghc/8.6.5/bin/runhaskell* lrwxrwxrwx. 1 ur20980 10 Mar 15 09:46 runhaskell-8.8 -> runghc-8.8* lrwxrwxrwx. 1 ur20980 27 Mar 15 09:46 runhaskell-8.8.3 -> ../ghc/8.8.3/bin/runhaskell* -rw-r--r--. 1 ur20980 8919264 Apr 16 09:41 x86_64-linux-ghcup-0.1.4 $Ah, did you install 8.8.3 and 8.6.5 via the old ghcup?
Actually, yes!
I think their symlinking is slightly different as can be seen. I need to account for that.
Not that I understand why it would be the case, but...
Regardless, I'm happy to see the current
ghcupmaster working (on my systems).Actually, I have to take some of the above back.
ghcuprebuilt from the source of the current master on MacOS:$ ghcup --url-source file:/Users/ur20980/src/ghcup-hs/ghcup-0.0.2.json list --cache Tool Version Tags Notes ✗ ghc 7.10.3 base-4.8.2.0 ✗ ghc 8.0.2 base-4.9.1.0 ✗ ghc 8.2.2 base-4.10.1.0 ✗ ghc 8.4.1 base-4.11.0.0 ✗ ghc 8.4.2 base-4.11.1.0 ✗ ghc 8.4.3 base-4.11.1.0 ✗ ghc 8.4.4 base-4.11.1.0 ✗ ghc 8.6.1 base-4.12.0.0 ✗ ghc 8.6.2 base-4.12.0.0 ✗ ghc 8.6.3 base-4.12.0.0 ✗ ghc 8.6.4 base-4.12.0.0 ✓ ghc 8.6.5 base-4.12.0.0 ✗ ghc 8.8.1 base-4.13.0.0 ✓ ghc 8.8.2 base-4.13.0.0 ✔✔ ghc 8.8.3 recommended,base-4.13.0.0 ✓ ghc 8.10.1 latest,base-4.14.0.0 ✗ cabal 2.4.1.0 ✗ cabal 3.0.0.0 ✔✔ cabal 3.2.0.0 latest,recommended ✔✔ ghcup 0.1.4 latest,recommended $ ll /Users/ur20980/.ghcup/cache/ghcup-0.0.2.json ls: /Users/ur20980/.ghcup/cache/ghcup-0.0.2.json: No such file or directory $ ghcup list [ Warn ] Could not get download info, trying cached version (this may not be recent!) [ Error ] Error fetching download info: FileDoesNotExistError "/Users/ur20980/.ghcup/cache/ghcup-0.0.2.json" $ ll /Users/ur20980/.ghcup/cache total 0 drwxr-xr-x 2 ur20980 179427977 64 Apr 15 21:45 ./ drwxr-xr-x 9 ur20980 179427977 288 Apr 15 23:27 ../ $ ghcup --version The GHCup Haskell installer, version 0.1.4 $ ghcup --numeric-version 0.1.4 $ ghcup debug-info [ Warn ] Could not get download info, trying cached version (this may not be recent!) [ Error ] Error fetching download info: FileDoesNotExistError "/Users/ur20980/.ghcup/cache/ghcup-0.0.2.json"Why doesn't it cache the relevant files? Placing the
--cacheargument before the commandlistdid not help or change anything.Update
Darn. Forgot to rebuild with
-fcurl. Re-doing that produced a working binary:$ ghcup debug-info Debug Info ========== GHCup base dir: /Users/ur20980/.ghcup GHCup bin dir: /Users/ur20980/.ghcup/bin GHCup GHC directory: /Users/ur20980/.ghcup/ghc GHCup cache directory: /Users/ur20980/.ghcup/cache Architecture: amd64 Platform: Darwin, General (Version {_vEpoch = Nothing, _vChunks = [[Digits 10],[Digits 15]], _vRel = []}) Version: 0.1.4 $ ghcup --cache list Tool Version Tags Notes ✗ ghc 7.10.3 base-4.8.2.0 ✗ ghc 8.0.2 base-4.9.1.0 ✗ ghc 8.2.2 base-4.10.1.0 ✗ ghc 8.4.1 base-4.11.0.0 ✗ ghc 8.4.2 base-4.11.1.0 ✗ ghc 8.4.3 base-4.11.1.0 ✗ ghc 8.4.4 base-4.11.1.0 ✗ ghc 8.6.1 base-4.12.0.0 ✗ ghc 8.6.2 base-4.12.0.0 ✗ ghc 8.6.3 base-4.12.0.0 ✗ ghc 8.6.4 base-4.12.0.0 ✓ ghc 8.6.5 base-4.12.0.0 ✗ ghc 8.8.1 base-4.13.0.0 ✓ ghc 8.8.2 base-4.13.0.0 ✔✔ ghc 8.8.3 recommended,base-4.13.0.0 ✓ ghc 8.10.1 latest,base-4.14.0.0 ✗ cabal 2.4.1.0 ✗ cabal 3.0.0.0 ✔✔ cabal 3.2.0.0 latest,recommended ✔✔ ghcup 0.1.4 latest,recommended $ ll ~/.ghcup/cache/ total 208 drwxr-xr-x 3 ur20980 179427977 96 Apr 28 15:39 ./ drwxr-xr-x 9 ur20980 179427977 288 Apr 15 23:27 ../ -rw-r--r-- 1 ur20980 179427977 104373 Dec 31 1969 ghcup-0.0.2.jsonI would still like a better version indicator...
Edited by Mouse-
I'm currently changing the default to build for curl and will add wget support.
$ ghcup list [ Warn ] Could not get download info, trying cached version (this may not be recent!) [ Error ] Error fetching download info: FileDoesNotExistError "/Users/ur20980/.ghcup/cache/ghcup-0.0.2.json"Yes, this is actually as expected, it falls back to the offline version now!
Edited by Julian Ospald I'm happy to report that the current master
- Builds successfully now (dynamic build!) on Mac and Linux.
- Correctly defaults to
curlwithout user having to specify flags during build. - Correctly accesses the server and does what it's supposed to.
Thanks!
$ git branch cross * master $ cabal configure && cabal install --overwrite-policy=always 'cabal.project.local' file already exists. Now overwriting it. Resolving dependencies... Build profile: -w ghc-8.8.3 -O2 In order, the following would be built (use -v for more details): - base64-bytestring-1.1.0.0 (lib) (requires build) - cmdargs-0.10.20 (lib) (requires build) - ghcup-0.1.4 (test:ghcup-test) (first run) - pretty-terminal-0.1.0.0 (exe:example) (requires build) - table-layout-0.9.0.0 (exe:table-layout-test-styles) (requires build) - text-conversions-0.3.0 (lib) (requires build) - aeson-pretty-0.8.8 (exe:aeson-pretty) (requires build) - string-interpolate-0.2.0.1 (lib) (requires build) - ghcup-0.1.4 (lib) (configuration changed) - ghcup-0.1.4 (exe:ghcup-gen) (configuration changed) - ghcup-0.1.4 (exe:ghcup) (configuration changed) Wrote tarball sdist to /home/ur20980/src/ghcup-hs/dist-newstyle/sdist/ghcup-0.1.4.tar.gz Resolving dependencies... Build profile: -w ghc-8.8.3 -O2 In order, the following will be built (use -v for more details): - ghcup-0.1.4 (lib) (requires build) - ghcup-0.1.4 (exe:ghcup-gen) (requires build) - ghcup-0.1.4 (exe:ghcup) (requires build) Starting ghcup-0.1.4 (lib) Building ghcup-0.1.4 (lib) Haddock ghcup-0.1.4 (lib) Installing ghcup-0.1.4 (lib) Completed ghcup-0.1.4 (lib) Starting ghcup-0.1.4 (exe:ghcup-gen) Starting ghcup-0.1.4 (exe:ghcup) Building ghcup-0.1.4 (exe:ghcup) Building ghcup-0.1.4 (exe:ghcup-gen) Installing ghcup-0.1.4 (exe:ghcup-gen) Completed ghcup-0.1.4 (exe:ghcup-gen) Installing ghcup-0.1.4 (exe:ghcup) Completed ghcup-0.1.4 (exe:ghcup) Symlinking 'ghcup' Symlinking 'ghcup-gen' $ hash -r $ ghcup list Tool Version Tags Notes ✗ ghc 7.10.3 base-4.8.2.0 ✗ ghc 8.0.2 base-4.9.1.0 ✗ ghc 8.2.2 base-4.10.1.0 ✗ ghc 8.4.1 base-4.11.0.0 ✗ ghc 8.4.2 base-4.11.1.0 ✗ ghc 8.4.3 base-4.11.1.0 ✗ ghc 8.4.4 base-4.11.1.0 ✗ ghc 8.6.1 base-4.12.0.0 ✗ ghc 8.6.2 base-4.12.0.0 ✗ ghc 8.6.3 base-4.12.0.0 ✗ ghc 8.6.4 base-4.12.0.0 ✓ ghc 8.6.5 base-4.12.0.0 ✗ ghc 8.8.1 base-4.13.0.0 ✗ ghc 8.8.2 base-4.13.0.0 ✔✔ ghc 8.8.3 recommended,base-4.13.0.0 ✓ ghc 8.10.1 latest,base-4.14.0.0 ✗ cabal 2.4.1.0 ✗ cabal 3.0.0.0 ✔✔ cabal 3.2.0.0 latest,recommended ✔✔ ghcup 0.1.4 latest,recommended $-
Cool. I pushed the rest to master, which now allows to choose the downloader:
When built with
-finternal-downloader:--downloader <internal|curl|wget> Downloader to use (default: internal)Without it:
--downloader <curl|wget> Downloader to use (default: curl)And there are two undocumented environment variables:
GHCUP_CURL_OPTSGHCUP_WGET_OPTS
Both just do simple white-space splitting on the arguments and pass it further.
I think we can close now.
Yep! And thank you very much!
P.S. Wouldn't it be better to always include all the three download options, and change only the default on invocation? For example,
- if built with
-finternal-downloaderthen:
--downloader <internal|curl|wget> Downloader to use (default: internal)- otherwise:
--downloader <curl|wget|internal> Downloader to use (default: curl)- if built with
-
P.S. Wouldn't it be better to always include all the three download options, and change only the default on invocation? For example,
-finternal-downloadercauses linking to OpenSSL, which causes portability issues (e.g. the ghcup binary wouldn't work on both FreeBSD 11 and 12). So it is off by default. -finternal-downloadercauses linking to OpenSSL, which causes portability issues (e.g. the ghcup binary wouldn't work on both FreeBSD 11 and 12). So it is off by default.Ah, I understand... Yes, what you did should be perfectly OK for the distributed binaries.
I'm still trying to find a way that would allow a user to build
ghcupfrom the source with all the three downloaders, but keepingcurlas default... What do you say/think?Because, e.g., when I build a binary on my system, I don't mind linking it with my OpenSSL (understanding that it's not likely to be portable) - but I'd prefer to have a reasonable default, which on my systems is
curl...Edited by Mouse
