Detect the client plateform for Stack installation instructions about haskell-lang

[borsboom]

TL;DR: I like the shell script installer, and we could have stack setup offer to add ~/.local/bin to the PATH in the user's profile (and also bash auto-completion) since that would work for both user-installed and Linux distro package-installed stack. stack upgrade should just print a big warning if ~/.local/bin isn't on the PATH.

Here's the thought process:

I think shell-script installer would be simplest (a user has to be able to use the command-line for Stack anyway). I like @snoyberg's suggestion of putting stack in .local/bin and updating the user's .profile, because that doesn't require any sudo (installer scripts that use sudo squick me out -- Docker's does because it actually needs root access and to run as a daemon to work, but Stack has no such requirements). It would also be nice if this installs bash auto-completion.

Separately, there's the question of Linux distro packages. I don't think there's a reliable way to get ~/.local/bin added to all users' PATHs (possibly by putting something in /etc/profile.d, but those are run before the user's profile and likely to have their PATH overridden).

We could kill two birds with one stone and have stack setup offer to add ~/.local/bin to the PATH in .profile when run interactively.

On stack upgrade: The idea of Stack updating a globally-installed binary (which may be under control of a package manager) seems wrong, even if the user does have sudo access. Instead, perhaps Stack could check for a newer ~/.local/bin/stack at startup and, if it exists and isn't already what's running, exec that instead of continuing. That way non-admin users on a multi-user system can still use stack upgrade seamlessly. Then again, if we make adding ~/.local/bin to PATH a part of setup, it'd probably be enough to just show a big warning on stack upgrade if ~/.local/bin isn't on the PATH (it could even call into the same logic as stack setup uses).

[chrisdone]

I agree, auto-detecting would be handy. I tried showing our Getting Started page to my non-technical guinea pig and that choice is a bit overwhelming. The OS X choice itself also presents Homebrew first, which she has no idea what that is. Clarifying this doesn't dumb anything down.

I'll take a crack at simplifying this choice today.

[chrisdone]

Hm, I think it should run stack setup automatically. It occurs to me that without GHC stack doesn't do much, and the first thing someone's likely to try will say "sorry I can't do anything, please run stack setup". When cabal says "please run configure" I feel like slapping it and shouting "do the needful!" Thoughts?

[snoyberg]

Pinging @borsboom, who handles the Stack release process and should be included in this discussion.

For Windows: we already have an installer (https://www.stackage.org/stack/windows-x86_64-installer). I haven't used it personally (I switched away from Windows before it was available), but I believe it's fully functional. So we've got that solved.

For OS X, Linux, and for that matter FreeBSD and others, what about having a shell script installer? It should be pretty simple:

• Use uname and friends to determine which executable to use
• Download it and place it in ~/.local/bin
• If ~/.local/bin isn't on the PATH, update the appropriate shell configuration depending on $SHELL
• Possibly: install to /usr/local/bin as well so that, just in case the shell config fails, Stack will still be available

The get started page would then have:

• Windows: click here
• Everyone else: wget https://www.haskell-lang.org/get-started.sh && sh get-started.sh (or use a curl pipe, which people seem to universally revile)

We can include the link to the install/upgrade page for more options, and highlight/focus on the Windows vs everyone else option based on OS detection. Which, if we just need to detect Windows vs not Windows, should be much simpler.

EDIT Also, I had a similar discussion on Reddit a few days ago: https://www.reddit.com/r/haskell/comments/4hfv3v/video_of_happy_learn_haskell_tutorial_setup_ghc/d2pmgr3

EDIT2 Prior art on the shell script so that we don't need to reinvent the wheel:

• https://get.docker.com/
• https://raw.githubusercontent.com/wayneeseguin/rvm/master/binscripts/rvm-installer

[chrisdone]

Okay, I've added the distro-specific package links, and a link to Stack's general manual docs on downloads too (see below). That pretty much covers this page as far as I'm concerned.

Now we need the infrastructure to back it up (the script and the download location).

[bitemyapp]

I'm a little hesitant to inject cleverness that could stymie people, but if it is done, perhaps only to put something at the top?

[bitemyapp]

Prior art along these lines worth considering: http://www.scala-lang.org/download/

[ThibaudDauce]

I though the link http://docs.haskellstack.org/en/stable/install_and_upgrade/ is enough to cover every needs. We just need to put a clever solution on top.

I may be blind but I can't see a page with download instructions for Windows for example in http://www.scala-lang.org/download/ only the Linux download button… (but maybe because it's Java there is no difference between tar.gz archives).

[bitemyapp]

@chrisdone sounds like a good thing to fix. Main thing I'd add is that they need to install Stack to get started and really do anything, but there's no visual emphasis for a call to action in the list-of-operating-systems soup.

[chrisdone]

I pushed a change on ci.haskell-lang.org. Not finished but it's a start. I
discovered that without the PATH being set automatically it's kinda hard
to use stack without knowledge of PATH stuff. Needs automating somehow.
On 5 May 2016 19:19, "Chris Allen" [email protected] wrote:

@chrisdone https://github.com/chrisdone sounds like a good thing to
fix. Main thing I'd add is that they need to install Stack to get started
and really do anything, but there's not much visual emphasis for a call to
action in list-of-operating-systems soup.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#35 (comment)

[bitemyapp]

@chrisdone this is why early in our Stack tutorial we explained the PATH. This is what people liked about the GHC For Mac OS X installer app — automatically added ghc et al. to the PATH after installation.

[chrisdone]

Yeah, we need that here.

• OS X: I believe I can learn enough XCode to make a drag-n-drop OS X program that is a "Command Line" project, so stack'll be on the PATH ready for use in the terminal.
• Windows: We need the Windows installer to do that, too.
• Linux: For Linux, it could probably offer to extract stack to ~/.local/bin and then if they're on bash, automatically add EXPORT PATH=~/.local/bin:PATH too.

Without this setup, we're kind of exclusive to existing programmers who know about PATH.

[chrisdone]

Yeah, if Windows is already sorted out then we could make a shell script for all the unixy platforms.

I think curl is what comes as default on OS X. I think for Ubuntu and the like, it's wget. It might be more straight-forward to say "download this script and run sh get-started.sh" or so.

[soenkehahn]

I'm always slightly angry at installation scripts that modify my shell config without my knowledge or consent. (But maybe that's just me, so feel free to ignore my 2 cents on this.)

At the same time I completely agree that stack should work out of the box for people who don't know about PATH (or don't bother to tweak it manually).

Maybe we could have something like:

Download get-started.sh and execute it (e.g. by doing wget http://example.com/get-started.sh && bash get-started.sh or
put the stack executable (download here) into your PATH.

[snoyberg]

Alright, I chatted with @chrisdone a bit right now about this. There are only two reasons why PATH modifications are necessary:

• So that stack upgrade will actually upgrade the Stack being used
• So that stack installed executables can be found

The second bullet isn't too terribly urgent: a first time user won't hit it right away, and Stack already loudly complains if the PATH isn't set.

The first one is more important. I recommend we change the behavior of stack upgrade ever so slightly:

• The new executable is copied over the currently running stack executable, not always into ~/.local/bin
• If the current process doesn't have access to write to that file, require that it be run with a --sudo option

I'm worried this is getting far too complicated though for a simple problem.

[snoyberg]

@chrisdone The downside of running stack setup is that it may download a different GHC than the user actually wants for the project he/she will be working on. If the user follows our step-by-step guide, he/she will end up installing GHC by running the hello world script. The flip side to the coin is that, for most people, bandwidth and disk space is cheap, so having an extra unused GHC isn't that terrible.

[chrisdone]

@snoyberg Yeah, that's a downside I was thinking about. Maybe it's okay to leave it then. It's not the end of the world, and this is one of the few cases stack tells the user to do something manual.

[chrisdone]

Okay, so to summarize:

• We have the Windows installer that sets everything up on Windows.
• Other distributions get a package for their preferred package manager.
• For the case of getting ~/.local/bin under the user's PATH, we have stack setup offer to apply it to their .profile file.
• Write a script for OS X, and and Linux, BSD, etc. that downloads the appropriate stack binary, and calls stack setup --profile (or whatever) that just adds the appropriate path info (installing GHC at this stage may waste the user's time).
• I'll update the getting-started page to show a choice of logos, the one you hit just slides down a guide for that OS:
  • For Windows, it's "Download and run this installer".
  • For Linux general and OS X, it's "Run this in the terminal."
  • For Ubuntu and other distros, it's "Add this to your whatever and run this."

I'm going to work on this now. I'm going to make the page super easy; it may seem like taking too much care, but this will be the first interaction point people have with Haskell, or something we as companies or educators will be linking our clients and colleagues to, so it's worth the effort making it smooth.

[borsboom]

You might just want to point most people toward the shell-script installer rather than the distro packages, since those may actually involve more steps to get working (getting the key, adding the deb/rpm repo, etc.). The shell script installer could also figure out the distro and use the appropriate package, but that would require sudo.

[chrisdone]

No problem, we can present that choice when they click on a distro. The script foremost and then a "and for people who want to use their package manager..." Working on this now.

[chrisdone]

I've pushed a set of changes to /get-started that you can check out.

I've still got to include the distro-specific packages instructions, and a general link to Stack's manual page. But this is the kind of UX I'm going for.