Support installing on macOS aka Darwin

Was this tested? get_distro_alias is applied to the output of get_distro_name, so does get_distro_name actually output Darwin?

I tested it on my machine yes; uname -s is Darwinon osx

Sent from my iPhone

On 12 Nov 2018, at 5.18, Julian Ospald notifications@github.com wrote:

Was this tested? get_distro_alias is applied to the output of get_distro_name, so does get_distro_name actually output Darwin?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

Do you think it would be worthwhile to make the distinction of platforms more explicit? As in: first check whether we are on linux, then check distro name, instead of just firing distro lookup logic.

However, I think it's currently not needed. get_distro_name is already written in a cross-platform fashion, right? (Except, I don't know how it deals with mingw, but FreeBSD should work as well).

It will be a good idea (won't do as part of this PR)

Before this patch ghcup fall back to Fedora (on macox, for 8.4.4), downloaded, unpacked, in fact proceeded quite long in the install before failing. I suspect that's what happens now in FreeBSD. So at the very least, ghcup should point out that it wasn't able to recognize system / distro (and as a bonus what it's falling back to).

So at the very least, ghcup should point out that it wasn't able to recognize system / distro (and as a bonus what it's falling back to).

I don't think it has to recognize every distro. In that case we will print a lot of warnings, just because we don't know a distro yet.

running with --verbose will already show exactly what tarball was chosen
install stage already prints: https://github.com/haskell/ghcup/blob/master/ghcup#L1101

In addition, there is a chance the fallback just works, even for an unknown system.

install stage already prints: https://github.com/haskell/ghcup/blob/master/ghcup#L1101

Before (and in fact after) this patch ghcup prints

Installing GHC-8.4.4 for Darwin on architecture x86_64"

But downloads a fedora tarball. This is very very confusing.

Fallback may just work only on Linux.

Should we change unknown to generic-linux; and let ghcup fail cleanly on non-supported non-Linux systems?

Should we change unknown to generic-linux; and let ghcup fail cleanly on non-supported non-Linux systems?

That sounds reasonable. At that point, we need to abstract over platforms though, otherwise it will become messy.

@hasufell the question of whether ghcup should warn/nag when it encounters something a new OS/distro or silently succeed comes down to the fundamental one whether we want to be explicit and try to keep maintain an accurate mapping of from distros to to bindists, which implies we want users to help us with keeping that compaibility database accurate by having ghcup warn a bit more saliently when it had to fallback so that the user can file a PR telling us that ghcup's heuristic did in fact work. Or do we want ghcup to silently install things, and let users only tell us when something breaks; iow, whether we want a positive-ack or negative-ack based workflow. Personally I prefer positive-ack biased workflows (especially for versioning schemes) as they give users more confidence that a specific config has been known to work for others (because ghcup would silently install a generic fallback, and if ghcup is too silent about it, it'll always remain a generic fallback even though we could have been told it is in fact a known-to-work configuration that doesn't need to be considered merely a generic fallback...)

I don't think it's reasonable to warn on unknown distros at all. For platforms, that can be done, not for distros.

@hasufell platforms as x86_64 vs i386?

I'd take a small step of linux vs. others now. Let not the best prevent progress.

After that I'd recommend moving towards LLVM triple: https://clang.llvm.org/docs/CrossCompilation.html#target-triple + linux distributions.

Then, in .download-urls we could use the triple(-wildcards) instead of arch.

# tool  version  arch                 distro   url
ghc     8.0.2    x86_84-apple-darwin  *        https://...-apple-darwin.tar.xz
ghc     8.0.2    x86_84-pc-linux-*    debian=8 https://...-deb8-linux.tar.xz
ghc     8.0.2    x86_84-pc-linux-*    *        https://...-unknown-linux.tar.xz

vendor, u.e apple and pc could be left as wildcard *
if triple cannot be determined, ghcup will abort early. (i think it does so if you run it on ARM device?)

Examples of triples:

my linux: x86_64-pc-linux-gnu
my co-workers' mac book: x86_64-apple-darwin17.7.0 (I think that the version 17.7.0 is the artifact of Apple's LLVM)

I could open an issue to discuss this separately.

if this PR is accepted, I recommend updating the README to reflect that all it targets all POSIX platforms (whether or not they currently work).

platforms as x86_64 vs i386?

ghcup already dies if it doesn't know the arch, I mean platform as in linux vs mac vs *bsd etc.

I could open an issue to discuss this separately.

Yes, that's a non-trivial change that will require changing the format.

Support installing on macOS aka Darwin

Merge request reports

Activity