Support Stackage better

[ndmitchell]

At the moment to setup Stackage you need wget on your PATH (not available as standard with Windows, although pretty easy to get) and you need to remember the URL. We could make that better by doing one of:

• Ship wget.exe and a stackage.bat file that does the appropriate command line.
• Have a stackage.exe binary (probably backed by a Cabal package on Hackage) that links in network and defaults to the right URL (that seems useful anyway). This could have more smarts, and wouldn't require wget.

Not sure if this should be moved to the Stackage tracker...

[akhra]

All you really need is an appropriate cabal.config in the root of your user folder. I'm actually not sure where it looks for that when running from cmd.exe, but from msys it's just ~ (i.e. /home/%USERNAME%) which is created by MinGHC in the first place. That can be a checkbox during installation.

Of course this won't get you nightly updates or anything. A stackage.exe that gets you the most recent nightly or LTS (depending on what's currently installed, with a commandline switch to override) would certainly be useful. If adding wget is viable (don't see why not, really) then it could instead be a stackage-update shell script which would be useful for every platform, or stackage.bat/stackage.cmd if it's considered essential for users to be able to run it from cmd.exe.

Actually, if it's going to be a fully Windows-native solution, commandline ftp is provided and takes a script. If there's an FTP source for Stackage, that would require no additional binaries.

[ndmitchell]

So far I've used Stackage on a per-project basis, so dump it in each project file separately. Not sure what's the "correct" way to do it though. I'd certainly want to run from cmd.exe, since that's how many Windows users do things, and it's not particularly a difficult script to write.

I'd be wary of FTP - its such ancient and rare technology that things like firewalls might object.

[snoyberg]

I'm definitely up for having some kind of a stackage helper executable that users can download do assist with these kinds of things. And I would also be in favor of including such an executable with minghc. I think the questions we'd need to answer mostly come down to what the functionality of this would be: would it prompt users to answer questions? Would it support global setup? And so on.

I haven't thought through this at all yet, I'll think some more on it tomorrow.

[ndmitchell]

I generally hate interactive question-based stuff, other than trivial "do you want to proceed y/n" questions. Otherwise I'm forever having to retype stuff that should be accessible in the command line history, and having a nightmare scripting stuff.

[akhra]

Something like:

stackage [global | init] [closed | open]
         [ constraint <label> [<version> | latest]
           | update ]

<label> = lts1 | nightly | none

Default to local, and output current/resulting configuration in every case (incl. stackage with no additional command). If there is currently no (user-)global config, create it with defaults open, none, latest. Local configuration is created only if a command other than update is given (and not global); otherwise, fall back to showing global config. With init, ignore any existing local settings. update is implied when setting a constraint.

Anything missing?

[snoyberg]

Pinging @chrisdone. I think having such a command line tool would be useful. We may want to rename the existing stackage package to stackage-build or something like that to simplify things for end users, and we should make sure to minimize dependencies in this new tool, since people will be installing it before they've set up Stackage.

[ndmitchell]

Note that either it must come with the ability to download a file (e.g. depends on the network library) or rely on a local tool (e.g. wget). Both of those choices mean it won't work for some subset of people - hence my desire to bundle it with MinGHC which can ship it as a binary or also ship wget and solve the issue.

I guess the alternative would be to release new versions of the stackage tool for each release, and have the constraints shipped with it, but that's a lot of new stackage tools.

[snoyberg]

I'm in favor of shipping the binary. I'm also not averse to include wget.exe.

But I thought that by including msys, everyone is now able to install network. Is that not true?

[ndmitchell]

There might be people who aren't using MinGHC who want to use the Stackage tool. Even with MinGHC, I wouldn't be shocked to find out that some small fraction of people still can't compile Network - it's certainly a very complex part.

[snoyberg]

We've just released a stackage-cli tool: https://www.fpcomplete.com/blog/2015/04/announcing-stackage-cli

[3noch]

@snoyberg This is extremely cool! I'm working very hard to get Haskell code into production for a Windows client app. (I'm guessing that's not the most common place for Haskell to show up.) These types of tools make Haskell so much more appealing, especially to newcomers.

[snoyberg]

Good, I'm glad you like it! More to follow :)

On Mon, Apr 20, 2015 at 7:41 PM Elliot Cameron notifications@github.com
wrote:

@snoyberg https://github.com/snoyberg This is extremely cool! I'm
working very hard to get Haskell code into production for a Windows client
app. (I'm guessing that's not the most common place for Haskell to show
up.) These types of tools make Haskell so much more appealing, especially
to newcomers.

—
Reply to this email directly or view it on GitHub
#19 (comment).

[3noch]

@snoyberg The current installer leaves out stackage-init which makes stackage-sandbox [init] impossible.

[snoyberg]

@DanBurton Can you look into providing an up-to-date https://github.com/fpco/minghc/blob/master/bin/stackage-cli.7z file with the missing executables?

[DanBurton]

I'll look into that today.

[3noch]

This seems done to me.

[snoyberg]

Good catch