Smart behavior for exec/ghc/etc commands outside of a project

[snoyberg]

Desired behavior: you're working on a project that uses LTS 2.9. You leave that project and go to a directory which has no stack.yaml file. You run stack runghc foo.hs. Instead of using some random snapshot, it should use the most recently used snapshot (LTS 2.9) so that there's a good chance that your desired libraries are available. It should also print out a message to the user explaining what happened and recommending a config file for more determinism.

[snoyberg]

Assigned to @DanBurton, but feel free to push back on the plan here if you have different ideas.

[DanBurton]

"Most recently used snapshot" seems like an easy thing to implement, but I'm not a big fan of using it for these use cases. I'd prefer to have the ability to specify a resolver at ~/.stack/stack.yaml, and have it use that.

[snoyberg]

I think I'd rather see something slightly different used: a separate config file for this case that acts as the "exec outside a project" project file. That way we keep a clear distinction between project-specific and global config settings. That file could be automatically generated for the user.

I'm still not completely on board with this being better, though. Being hidden away from the user, the user is unlikely to remember that this is being done for them, and won't think to look in ~/.stack to upgrade to a newer GHC or snapshot.

[snoyberg]

Reassigning to @dysinger. We're going to start off with the design I originally laid out, and consider other improvements for future releases.

[snoyberg]

Be sure to look at 36a6714, which includes a clean place to implement this.

[bitemyapp]

[callen@atlantis ~/Work/fpbook]$ stack --version
Version 0.0.0, Git revision 39db6c7b3e9586753d5e41f80f60c44174d2fa3f

[callen@atlantis ~/Work/fpbook]$ stack ghci
stack: You do not have a stack.yaml. This will be handled in the future, see https://github.com/fpco/stack/issues/59

[callen@atlantis ~/Work/fpbook]$ ls -alh

...unnecessaries elided...

-rw-rw-r--   1 callen  512 Jun  7 17:44 fpbook.cabal

Title of this ticket says, "outside of a project".

I do have a project, have I missed something?

[snoyberg]

Project means a stack.yaml file, not a cabal file.

On Mon, Jun 8, 2015, 1:48 AM Chris Allen [email protected] wrote:

[callen@atlantis ~/Work/fpbook]$ stack --version
Version 0.0.0, Git revision 39db6c7

[callen@atlantis ~/Work/fpbook]$ stack ghci
stack: You do not have a stack.yaml. This will be handled in the future, see #59

[callen@atlantis ~/Work/fpbook]$ ls -alh

...unnecessaries elided...

-rw-rw-r-- 1 callen 512 Jun 7 17:44 fpbook.cabal

Title of this ticket says, "outside of a project".

I do have a project, have I missed something?

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

[bitemyapp]

@snoyberg ordinarily it creates a default one, why didn't it do so in this case?

[snoyberg]

@bitemyapp That's the goal of the ticket: not to create spurious projects when you just want to run ghci or runghc, but instead to reuse a preexisting environment that already has packages installed.

[chrisdone]

• Have a ~/.stack/global/stack.yaml config file.
• Somewhere in ~/.stack/global will be the usual installed package database.
• In ExecStrategy:
  • Choose the latest LTS.
  • Create a Project config type with empty fields apart from projectResolver.

When running e.g. stack ghc that'll create this config file (or load it in) and proceed as normal.

[snoyberg]

One other point: we should have some way of letting the user know that they're using the implicit global and how to change the snapshot it uses.

[ghost]

A default gloabl config file were good .

I pefered using stack to auto install ghc and packages automatic.

so , when i need run ghci anywhere, I just want to type stack ghci

[chrisdone]

Implemented in afb074e. Now if I run stack ghc it'll say this:

chris@retina:~$ stack ghc -- X.hs -o x.hs
Using latest snapshot resolver: lts-2.14
Writing global (non-project-specific) config file to: /home/chris/.stack/global/stack.yaml
Note: You can change the snapshot via the resolver field there.

X.hs:3:8:
    Could not find module ‘Lucid’
    Use -v to see a list of the files searched for.
chris@retina:~$ stack ghc -- X.hs -o x.hs

X.hs:3:8:
    Could not find module ‘Lucid’
    Use -v to see a list of the files searched for.

(Subsequent runs don't warn about this.)

Then I can go ahead and change the resolver in my stack.yaml to be lts-2.9 (which is what my ~/Work/stack/stack.yaml has), and now it compiles:

chris@retina:~$ stack ghc -- X.hs -o x.hs
[1 of 1] Compiling Main             ( X.hs, X.o )
Linking x.hs ...
chris@retina:~$ 

And I can load up GHCi and load Lucid happily:

chris@retina:~$ stack ghci
GHCi, version 7.8.4: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> import Lucid
Prelude Lucid> 

Alternatively, if I want a separate global snapshot, I want to use the latest 2.14 one, then I can install lucid into that instead:

chris@retina:~$ stack install lucid
text-1.2.0.6: configure
text-1.2.0.6: build
text-1.2.0.6: install
hashable-1.2.3.2: downloading
blaze-builder-0.4.0.1: downloading
hashable-1.2.3.2: configure
blaze-builder-0.4.0.1: configure
hashable-1.2.3.2: build
blaze-builder-0.4.0.1: build
hashable-1.2.3.2: install
blaze-builder-0.4.0.1: install
unordered-containers-0.2.5.1: downloading
unordered-containers-0.2.5.1: configure
unordered-containers-0.2.5.1: build
unordered-containers-0.2.5.1: install
lucid-2.9.2: configure
lucid-2.9.2: build
lucid-2.9.2: install
Completed all 5 actions.
chris@retina:~$ stack ghc -- X.hs -o x.hs
[1 of 1] Compiling Main             ( X.hs, X.o )
Linking x.hs ...

[chrisdone]

@snoyberg Can you review? afb074e Pretty simple but I might've missed something.

[snoyberg]

This doesn't look right. Running stack build outside of a project succeeds when it shouldn't.

[snoyberg]

Recent commits fixed all issues with this, closing.