'stack build' succeeds while 'stack ghci' doesn't. Prelude missing?

[ce-dot]

This might or might not relate to #665.

I see the following for stack version 0.1.3.1, Git revision ebda694 (1662 commits) X86_64, using stackage lts-3.2 (yesod-bin needs to be installed).
Execute in order and choose the mini template when prompted:

mkdir testproj 
cd testproj
stack exec -- yesod init -n testproj --bare
stack init
stack build
stack ghci

The last command fails to produce a working ghci session, full log (these setlocale issues are not in the 0.1.3.1 release): https://gist.github.com/RGamma/4f6911292e6f20ace7f2

A workaround is to add import Prelude to each Haskell file in the directory, run stack clean followed by stack ghci.

[snoyberg]

This is because the yesod scaffolding is inconsistent in its usage of
NoImplicitPrelude in different components. I'm in favor of fixing that.

On Mon, Aug 24, 2015, 10:55 PM RGamma [email protected] wrote:

This might or might not relate to #665
#665.

I see the following for stack version 0.1.3.1, Git revision ebda694
ebda694
(1662 commits) X86_64, using stackage lts-3.2 (yesod-bin needs to be
installed).
Execute in order and choose the mini template when prompted:

mkdir testproj
cd testproj
stack exec -- yesod init -n testproj --bare
stack init
stack build
stack ghci

The last command fails to produce a working ghci session, full log (these
setlocale issues are not in the 1.3.1 release):
https://gist.github.com/RGamma/4f6911292e6f20ace7f2

A workaround is to add import Prelude to each Haskell file in the
directory, run stack clean followed by stack ghci.

—
Reply to this email directly or view it on GitHub
#847.

[ce-dot]

I don't see any reference to NoImplicitPrelude anywhere in the scaffolding, neither in the cabal file nor any other source file.

It just made me wonder what stack ghci does differently from stack build regarding the imports.

[snoyberg]

The library component defines NoImplicitPrelude at https://github.com/yesodweb/yesod-scaffold/blob/0fb802b9c7a48f4f82cf818ab985096e194e7cdb/PROJECTNAME.cabal#L35. The test suite component, by contrast, does not define NoImplicitPrelude: https://github.com/yesodweb/yesod-scaffold/blob/0fb802b9c7a48f4f82cf818ab985096e194e7cdb/PROJECTNAME.cabal#L102.

[snoyberg]

Sorry, test suite was incorrect, I meant the executable doesn't define NoImplicitPrelude.

[snoyberg]

Never mind, on closer reading I see you're talking about the mini template, which doesn't define such language extension. This isn't an input problem then.

[ce-dot]

I'm sorry, I should have been more clear about the 'mini' template.

If you trace my initial steps, but choose the 'simple' template instead (which does have yesod's Prelude trickery in it), stack ghci works as intended: Ok, modules loaded: Application, Import, Settings, Handler.Common, Handler.Home, Foundation, Import.NoFoundation, Settings.StaticFiles.

Edit: I should read all comments before replying...

[nmk]

I am seeing the same with a fresh project created with stack new, so this might not be yesod related at all. https://gist.github.com/nmk/75c7ba95917608ba8c69

stack build and stack test work as intended.

stack ghci foobar:test:foobar-test and stack ghci :foobar-test both fail with

Using main module: Package `foobar' component test:foobar-test with main-is file: /Users/nmk/code/haskell/foobar/test/Spec.hs
Configuring GHCi with the following packages: foobar
GHCi, version 7.10.2: http://www.haskell.org/ghc/  :? for help

<interactive>:1:1:
    Failed to load interface for ‘Prelude’
    It is a member of the hidden package ‘base-4.8.1.0’.
    Use -v to see a list of the files searched for.

[PierreR]

I have a similar problem with language-puppet. stack build works fine but stack ghci is failing with:

Puppet/Interpreter/Types.hs:891:34:
    No instance for (Field1 PPosition PPosition Position Position)
      arising from a use of ‘_1’
    In the first argument of ‘(.)’, namely ‘_1’
    In the second argument of ‘(.)’, namely ‘_1 . lSourceName’
    In the first argument of ‘use’, namely
      ‘(curPos . _1 . lSourceName)’

https://github.com/bartavelle/language-puppet/blob/master/stack.yaml

PS: everything works fine with cabal repl.

[snoyberg]

@PierreR Can you try with the most recent Stack release and/or master? I'm having no such problem currently.

Similarly @RGamma, I believe the problem you're reporting no longer occurs with master.

[PierreR]

I will do as soon as 0.1.5.0 is released on arch linux. It fails using 0.1.4.1

[ce-dot]

So I deleted my local stack config in ~/.stack, and installed stack's current git master from AUR (Version 0.1.5.0, Git revision 4b18f00 (2222 commits) x86_64), did stack install yesod-bin cabal-install --install-ghc and retried the sequence of steps in my first comment.

stack ghci still fails in the way described above, but stack build finishes fine: https://gist.github.com/RGamma/59e9c8428419bb8217d3 (this time it's lts-3.7), it should be easily reproducible for everyone.

[snoyberg]

I'm unable to reproduce the problem on my system, I don't know what the difference would be. Could you somehow test on another system to see if you still reproduce?

[ce-dot]

I tested the entire thing in VirtualBox as follows (takes some setup time, but at least it's reproducible):
Downloaded Ubuntu 15.04, installed it, upgraded all packages to newest version and restarted, added the Ubuntu 15.04 stack repo as detailed in the wiki, installed stack from there, ran (as root) stack upgrade --git (might fail because of missing system libraries, just install them with apt and rerun the command; don't forget to prepend the appropriate .local/bin path to PATH! At the time of testing: Version 0.1.5.0, Git revision 1b0b453df18d0ec0a6d6bcc58e904857c5576887 x86_64).
Do stack new testp yesod-minimal; cd testp, do stack build, which succeeds, but stack ghci fails as detailed before.

Edit: Possibly something to do with your env @snoyberg?

[snoyberg]

I'll test this out. Just to confirm: did you test this with the deb-installed version of Stack as well? Did that succeed, or fail?

[snoyberg]

I'm using the exact same version of stack, on an EC2 instance running Ubuntu 14.04, and unable to reproduce. Maybe it's a problem in 15.04 and Arch... which would be very strange. What's your stack ghci --verbose log look like?

[PierreR]

Here is my output using stack-0.1.4:
http://lpaste.net/142122

As a reminder, stack install does work (and if I use cabal, cabal repl does work as well)

[PierreR]

Note that vector-0.10.12.3 comes from the haskell-core repo of arch linux, not stackage.

[ce-dot]

I'm getting to the root of this, this seems to be a permission issue.
You'll notice that if you follow the procedure as root, the directories and files created by stack in ~/.stack (these don't matter here I think) as well as in the new project directory are more restrictive (as they are when I do this on my Arch machine as regular user!).

Ubuntu root: https://gist.github.com/RGamma/ce6237ec9f5886e459d7
Ubuntu regular: https://gist.github.com/RGamma/3edc07fbcc1535b96fc1
Furthermore if you create a new project (call it testp) as root, then chmod 664 testp/.ghci (i.e. add group write permission), stack ghci will succeed in that project.

With the regular user you can recreate the failure if you: stack new testp yesod-minimal; chmod 755 testp; cd testp; chmod 644 .ghci; stack ghci

In summary: If the project directory and .ghci file are missing group write privileges, the failure occurs. To work around this you need to add group write permissions to at least one of project directory or.ghci.

One a side note: The suggested fix for the warning you give when the project directory has group write permission (chmod 644 testp) is incorrect, because you need execute permissions to enter a directory (should be 744 then)

Edit: One can of course use chmod g+-w <file> notation to be sure to not change anything else.

Edit 2: Sure enough, the umask for my regular user on the Arch machine is 022 (default directory permission 755, file permission 644) instead of 002 in the Ubuntu VM (default directory permission 775, file permission 664)

[borsboom]

We have #471 to prevent running under sudo by default.

[ce-dot]

@borsboom, note that this wouldn't help people on distributions with a different default umask (Arch sets this in /etc/profile). If the cause of this issue will/can not be fixed, then some sort of warning should be implemented (In fact, I still don't really see why specifically missing write privileges would be causing such nondescript errors by ghci).

[PierreR]

As note, my problem is probably different because I have tried the suggestions above and it didn't make a difference. So if this issue is fixed, I would probably have to create a new one.

[snoyberg]

I'm going to close this issue; I'm not quite certain what point is still being discussed here due to the various problems being raised together here. If there are still changes desired in Stack not reflected in other issues, please open up a new issue.

[adam-singer]

I've recently hit a similar issue here, but I'm doing all kinds of mixing on a fakakta environment to satisfy some legacy constraints. Shortest way to explain the env nilcons/ghc-musl + source built stack-1.0.1 + running as root. I've tried adding the NoImplicitPrelude and some old import hacks to no avail. Only happens when trying to invoke ghci, builds, installs and execution works fine. I do hit a pain point of having to reconfigure when sharing a mount point between container and host, but ya, I'm sharing a mount point, what should I expect :)

[1 of 5] Compiling Foundation       ( Foundation.hs, interpreted )

Foundation.hs:11:1: Not in scope: type constructor or class ‘Int’

Foundation.hs:11:1: Not in scope: type constructor or class ‘Int’
Failed, modules loaded: none.

<no location info>:
    Could not find module ‘Add’
    It is not a module in the current program, or in any known package.
>

[mgsloan]

@financecoding Feel free to open a new issue with the output of stack ghci -v.

Does stack ghci warn you about problematic default extensions? Unfortunately, having lots of default-extensions doesn't play well with loading multiple packages at once into ghci, and yesod-scaffold currently has lots of these. Do you have multiple packages?

[gambogi]

my project .ghci was writeable by world. stack ghci provided the following warning:

*** WARNING: /home/gambogi/projects/run/rundex/.ghci is writeable by someone else, IGNORING!
Suggested fix: execute 'chmod go-w $PROJECTDIR/.ghci' 

I ran chmod go-w $PROJECTDIR/.ghci as was suggested and then things like IO went out of scope.

[mgsloan]

@gambogi That warning is provided by ghci itself. If you have a custom .ghci script, then it will use that, potentially changing what gets loaded / imported into ghci.