Closed hasufell closed 1 year ago
In GitLab by @maerwald on Apr 26, 2020, 17:40
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-info
is currently still a command (unlike --version
and --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 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,
ghcup
built 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:
cabal build -fcurl
)Try with -fcurl
and report back.
In GitLab by @mouse07410 on Apr 26, 2020, 22:47
debug-info
is currently still a command (unlike--version
and--numeric-version
). Before any command runs, ghcup checks for a new version. I find this reasonable.
I don't, given the result. Recommendation:
upgrade
command only;debug-info
like --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.json
to 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
-fcurl
and report back.
Let me begin with expressing my strong dislike for (2), because of how it (doesn't) handle web proxies.
With -fcurl
it builds, installs, and fails on attempt to fetch ghcup-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":
. . . . .
In GitLab by @maerwald on Apr 26, 2020, 23:04
- do that check only for some of the commands;
That's what I said.
- make that check a part of
upgrade
command only;
No. We want that for list and everything else as well. Users should be annoyed for not upgrading.
- make
debug-info
like--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.json
to 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
-fcurl
it 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
In GitLab by @mouse07410 on Apr 26, 2020, 23:27
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.json
to 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
-fcurl
it builds, installs...... use the local version ...
--url-source ...
The --url-source
works. It would be nice if this flag (and --cache
- BTW, what exactly does it do?) were included in the --help
output.
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-curl
is specified.
P.S. When do you think ghcup-0.0.2.json
would end up on the main web site, obviating the need to specify --url-source ...
flag?
In GitLab by @maerwald on Apr 27, 2020, 02:21
We differ on this. Given my experience with the recent upgrades, I think my position is understandable.
I cannot follow.
The
--url-source
works. It would be nice if this flag (and--cache
- BTW, what exactly does it do?) were included in the--help
output.
--cache is already in the help output:
-c,--cache Cache downloads in ~/.ghcup/cache
--url-source
is 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-curl
is 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.json
would 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 cross
branch of this repo, it also contains a lot of bugfixes.
In GitLab by @mouse07410 on Apr 27, 2020, 02:33
--url-source
is 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
cross
branch 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.
In GitLab by @maerwald on Apr 27, 2020, 03:01
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.
In GitLab by @mouse07410 on Apr 27, 2020, 04:09
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 curl
installations would require -k
, but that's not something desirable in general...
Yes, I uploaded
ghcup-0.0.2.json
Thank you!
In GitLab by @maerwald on Apr 27, 2020, 04:57
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
curl
installations would require-k
, but that's not something desirable in general...
My distro solves this by allowing an environmet variable EXTRA_CURL
or 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.
In GitLab by @mouse07410 on Apr 27, 2020, 05:11
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_ARGS
env var?
On one machine (Mac) cross
branch 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)...
In case it matters: building the current master
branch 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
$
In GitLab by @maerwald on Apr 27, 2020, 21:47
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 --version
on 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/
In GitLab by @mouse07410 on Apr 27, 2020, 22:23
Wow, that is interesting
Producing interesting cases is my specialty. ;-)
Can you run
ghcup --version
on 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.
In GitLab by @maerwald on Apr 27, 2020, 22:26
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.4
If 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.
In GitLab by @mouse07410 on Apr 27, 2020, 22:30
$ 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,recommended
In GitLab by @maerwald on Apr 27, 2020, 22:38
Can you post the output of find ~/.ghcup
on the Centos one?
In GitLab by @mouse07410 on Apr 27, 2020, 22:41
Can you post the output of
find ~/.ghcup
on 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
$
In GitLab by @maerwald on Apr 28, 2020, 01:56
Ah, did you install 8.8.3 and 8.6.5 via the old ghcup? I think their symlinking is slightly different as can be seen. I need to account for that.
In GitLab by @mouse07410 on Apr 28, 2020, 02:09
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 ghcup
master working (on my systems).
In GitLab by @mouse07410 on Apr 29, 2020, 03:33
Actually, I have to take some of the above back.
ghcup
rebuilt 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 --cache
argument before the command list
did not help or change anything.
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.json
I would still like a better version indicator...
In GitLab by @maerwald on Apr 29, 2020, 03:45
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!
In GitLab by @mouse07410 on Apr 29, 2020, 22:22
I'm happy to report that the current master
curl
without user having to specify flags during build.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
$
In GitLab by @maerwald on Apr 30, 2020, 01:46
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_OPTS
GHCUP_WGET_OPTS
Both just do simple white-space splitting on the arguments and pass it further.
I think we can close now.
In GitLab by @maerwald on Apr 30, 2020, 01:46
closed
In GitLab by @mouse07410 on Apr 30, 2020, 01:52
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,
-finternal-downloader
then:
--downloader <internal|curl|wget>
Downloader to use (default: internal)
--downloader <curl|wget|internal>
Downloader to use (default: curl)
In GitLab by @maerwald on Apr 30, 2020, 01:58
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-downloader
causes 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.
In GitLab by @mouse07410 on Apr 30, 2020, 02:01
-finternal-downloader
causes 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 ghcup
from the source with all the three downloaders, but keeping curl
as 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
...
In GitLab by @maerwald on Apr 30, 2020, 04:01
I'm still trying to find a way that would allow a user to build
ghcup
from the source with all the three downloaders, but keepingcurl
as default
Use a shell alias: alias ghcup='ghcup --downloader=curl'
.
In GitLab by @mouse07410 on Apr 26, 2020, 10:26
Environment
MacoS Catalina and Linux CentOS 8. Cabal-3.2.0.0, ghc-8.8.3. Current master of this repo.
Problem
On all of my platforms,
ghcup
built from the master completely fails on the network access: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.