search

haskell / ghcup-hs

https://www.haskell.org/ghcup/
GNU Lesser General Public License v3.0
284 stars 88 forks source link

Current master fails to reach over the network... #28

Closed hasufell closed 1 year ago

hasufell commented 4 years ago

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.

$ ~/.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.

hasufell commented 4 years 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:

  1. with curl, which is what all shipped binaries do (run: cabal build -fcurl)
  2. 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.

hasufell commented 4 years ago

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:

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:

  1. with curl, which is what all shipped binaries do (run: cabal build -fcurl)
  2. 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":
. . . . .
hasufell commented 4 years ago

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 fetch ghcup-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
hasufell commented 4 years ago

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 distribution

That 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?

hasufell commented 4 years ago

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.

hasufell commented 4 years ago

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.

hasufell commented 4 years ago

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.

hasufell commented 4 years ago

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!

hasufell commented 4 years ago

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.

hasufell commented 4 years ago

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?

Update

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)...

Update 2

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
$
hasufell commented 4 years ago

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/

hasufell commented 4 years ago

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.

hasufell commented 4 years ago

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.

hasufell commented 4 years ago

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
hasufell commented 4 years ago

In GitLab by @maerwald on Apr 27, 2020, 22:38

Can you post the output of find ~/.ghcup on the Centos one?

hasufell commented 4 years ago

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
$
hasufell commented 4 years ago

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.

hasufell commented 4 years ago

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).

hasufell commented 4 years ago

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.

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.json

I would still like a better version indicator...

hasufell commented 4 years ago

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!

hasufell commented 4 years ago

In GitLab by @mouse07410 on Apr 29, 2020, 22:22

I'm happy to report that the current master

  1. Builds successfully now (dynamic build!) on Mac and Linux.
  2. Correctly defaults to curl without user having to specify flags during build.
  3. 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      
$
hasufell commented 4 years ago

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:

Both just do simple white-space splitting on the arguments and pass it further.

I think we can close now.

hasufell commented 4 years ago

In GitLab by @maerwald on Apr 30, 2020, 01:46

closed

hasufell commented 4 years ago

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,

hasufell commented 4 years ago

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.

hasufell commented 4 years ago

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...

hasufell commented 4 years ago

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 keeping curl as default

Use a shell alias: alias ghcup='ghcup --downloader=curl'.