stack init --solver should install and use its own GHC

[wereHamster]

I thought one of the reasons for stack is that it can be used to manage GHC. However, when I try to init a project with --solver (can't use stackage because of version incompatibilities), I get this:

$ stack init --solver
Executable named ghc not found on path: $PATH...

I was expecting stack to automatically use the latest stable GHC automatically (currently 7.10.x). Cabal does find a valid build plan when using GH 7.10.

[snoyberg]

Looks like a dupe of #1072, which was implemented on master. Can you try out the latest master and see if it works for you?

[wereHamster]

Not working on 0.1.6.0:

~/stack-0.1.6.0-osx-x86_64/stack init --solver --force                                                                                                                  18:22
Writing default config file to: $PWD/stack.yaml
Basing on cabal files:
- $PWD/my-project.cabal

No GHC on path, selecting: 7.10.2
Solver requires that cabal be on your PATH
Try running 'stack install cabal-install'

I did stack setup before which installed GHC 7.10.2, and stack ghci works just fine.

[borsboom]

@wereHamster Are you sure this is the same error? I think the No GHC on path, selecting: 7.10.2 is it telling you that it's using the stack-installed GHC rather than the one on your system path. The real error is Solver requires that cabal be on your PATH. Try running stack install cabal-install if you haven't already.

The messages here are kind of unclear, should be clarified which part is actually an error and what is just for information.

[wereHamster]

Fair point about GHC being installed. Though my larger goal of this issue was to make stack init --solver work OOTB. We're not there yet. For example: If stack knows that it needs cabal and that cabal is missing, why won't stack install cabal automatically?

If you prefer to close this issue and open a new one for making stack init --solver work properly, that'd be fine by me.

[borsboom]

Much like Stack doesn't install GHC automatically (it requires you to run stack setup), it also doesn't install tools like cabal automatically, but it does provide you an easy way to do so and tells you how (e.g. run stack install cabal-install).

I suppose an argument could be made that having an option to install tools automatically could exist (like --install-ghc, but that applies to everything instead of just GHC). A PR to that effect would be fine.

[harendra-kumar]

PR #1583 adds support for --install-ghc to stack new/init/solver commands.

[wereHamster]

What is the reason not to install GHC automatically, i.e invert the logic and provide a --no-install-ghc flag?

[mgsloan]

I agree with @wereHamster, let's make it a default! stack init is a sufficiently magical command that it seems fine to have it default to setting up ghc.

I don't think it can succeed without having the right ghc installed, right? So may as well default to solving this issue.

[harendra-kumar]

Installing GHC is an infrequent but a bit expensive (might be subjective) operation taking a bit more resources (time, bandwidth, space) than any other everyday operations. I like least user intervention and doing the right thing automatically but it might come with surprises sometimes. A user may not expect it to do something like that and she may have the GHC installed already but not on path, or may want to use a different snapshot/GHC version which is already installed.

A middle ground might be to interactively prompt the user for a yes/no for install, with a yes as the default. This behavior can be based on whether we have a terminal otherwise use the command line control.

Changing the default is easier though. We can try that and see if anyone complains!

[snoyberg]

The current default came about from people complaining about a tool doing
something like a GHC install automatically. I personally think auto install
would be a better default, but it's easier to teach people about stack
setup than to warn all people in bandwidth constrained environments to
change their defaults before using Stack.

On Sun, Jan 3, 2016, 9:11 AM Harendra Kumar [email protected]
wrote:

Installing GHC is an infrequent but a bit expensive (might be subjective)
operation taking a bit more resources (time, bandwidth, space) than any
other everyday operations. I like least user intervention and doing the
right thing automatically but it might come with surprises sometimes. A
user may not expect it to do something like that and she may have the GHC
installed already but not on path, or may want to use a different
snapshot/GHC version which is already installed.

A middle ground might be to interactively prompt the user for a yes/no for
install, with a yes as the default. This behavior can be based on whether
we have a terminal otherwise use the command line control.

Changing the default is easier though. We can try that and see if anyone
complains!

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

[wereHamster]

It doesn't make sense to create a new stack project without having a compiler on the system. If it is clearly visible in the output what stack is doing (eg. "Compiler not found, installing GHC 7.10.3"), the user can easily abort the operation (^C) and investigate.

I wouldn't use prompts or anything that requires interaction because that makes automated installs harder.

For bandwidth constrained environments it may be better to ask for permission for every network access, regardless of size (eg. "Need to download GHC 7.10.3 (approx. 248MB). Continue? [y/n]: "). Also, the size of all dependencies of an average project is about the same as GHC, so I don't see why we should have to explicitly allow one but not the other.

[harendra-kumar]

I wouldn't use prompts or anything that requires interaction because that makes automated installs harder.

You still have command line control (--install-ghc) for automated installs, if you use the right command line option no prompts will be displayed.

Prompting for every network access might be inconvenient. IIRC @mgsloan proposed a --offline option to disable network access which sounds the right way to control network access.

But this debate is about the default for a specific case of GHC. If it is true that average dependency download is of the same order as GHC then excepting GHC may not make sense. Installed size might still be a consideration though.

Here is the tar and installed size of GHC on my machine:

cueball:~/.stack/programs/x86_64-linux$ du -sm ghc-7.10.2 ghc-7.10.2.tar.xz 
1047    ghc-7.10.2
88  ghc-7.10.2.tar.xz

I am not sure if that is big or small, may depend on the setup and the user.

[mgsloan]

I can certainly see the potential for frustration when automatically downloading something. I've blown through my cellphone data before because I ^C'ed a docker pull and it kept on going in the background. Argh! So yeah, lets not do that.

As @wereHamster mentions, how about having init, new, and solver be interactive commands? We've usually avoided interactive commands, for the benefit of scriptability, but it doesn't seem very useful to write scripts involving init, new, or solver. A --non-interactive flag can also be added for this circumstance. We've already got plans to make new interactive. There are also plans to make solver interactive.

I'm not sure if it'd be worth the complexity of making snapshot search / selection interactive, but that's also something that could be considered.

[snoyberg]

I believe this issue has come to resolution, closing.