New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

yesod devel fails when using GHC 8 #1304

Closed
SamDM opened this Issue Nov 21, 2016 · 22 comments

Comments

Projects
None yet
5 participants
@SamDM
Copy link

SamDM commented Nov 21, 2016

Using lts-7.9 with the yesod-simple template works (i.e. it compiles, after some changes, see this issue and this diff). That is, stack build and stack test work as they should.

Unfortunately, stack exec -- yesod devel does not. It gives the following error:

app/devel.hs:2:1: error:
Failed to load interface for ‘Application’
It is a member of the hidden package ‘yesodGhc8-0.0.0@yesodGhc8-0.0.0-50I4TO8rJLD744gHxjnYos’.
It is a member of the hidden package ‘yesodGhc8-0.0.0@yesodGhc8-0.0.0-GxI8989ntrHKHxlvhuMbCe’.

I did check that I am using the correct yesod binary:

$ stack exec which
/home/sam/.stack/snapshots/x86_64-linux/lts-7.9/8.0.1/bin/ye‌​sod

See also the original Stackoverflow question here.

@snoyberg snoyberg changed the title `stack exec -- yesod devel` fails when using lts-7.9 yesod devel fails when using GHC 8 Nov 23, 2016

@snoyberg

This comment has been minimized.

Copy link
Member

snoyberg commented Nov 23, 2016

I tweaked the title to hopefully make this more obvious to other people wanting to report this (I know someone commented about it on Twitter or Reddit, I just don't remember who right now).

This looks related to #1284. I thought we had this fixed, but apparently not.

IMO, it's high time to do a fairly substantial rewrite of yesod devel, to do something more simple like call stack build --fast --file-watch package-name:lib --exec launch-dev-server. It's not quite that simple, and will certainly break some existing workflows, but I think the reduced complexity in yesod-bin would be worth it.

snoyberg added a commit that referenced this issue Nov 23, 2016

Rewrite yesod devel based on Stack #1304
Please see ChangeLog for explanation.

@snoyberg snoyberg self-assigned this Nov 23, 2016

@snoyberg

This comment has been minimized.

Copy link
Member

snoyberg commented Nov 23, 2016

Alright, I've just pushed a commit to 1304-stack-based-devel which will hopefully work much nicer. Would you mind giving it a shot? You should:

  • Clone this repo and check out the 1304-stack-based-devel branch
  • Run stack install yesod-bin inside the repo
  • Run yesod devel (not stack exec yesod devel) inside your project

It's working so far for me, but I'd appreciate some initial feedback from someone else before going to the wider community with this.

@SamDM

This comment has been minimized.

Copy link

SamDM commented Nov 24, 2016

Hi, I gave it a try and yesod devel seems to work again.

There is another issue however, and I'm not sure if it is related to yesod itself. I used to be able to launch the REPL with stack exec cabal repl and now I get this issue:

Package has never been configured. Configuring with default flags. If this
fails, please run configure manually.
cabal: Use of GHC's environment variable GHC_PACKAGE_PATH is incompatible with
Cabal. Use the flag --package-db to specify a package database (it can be used
multiple times).

When I run the 'old' version of yesod again (i.e. stack exec yesod devel, which of course fails after it is done compiling my application) and then run stack exec cabal repl , I am able launch my application from the REPL.

Anyway, thx for your incredibly fast feedback on this issue :)

@snoyberg

This comment has been minimized.

Copy link
Member

snoyberg commented Nov 24, 2016

I'm shocked that stack exec cabal repl ever worked: cabal really doesn't like the GHC_PACKAGE_PATH environment variable. Any reason not to use stack ghci?

@SamDM

This comment has been minimized.

Copy link

SamDM commented Nov 24, 2016

The reason I used it is this wiki page. This page is referenced to from app/DevelMain.hs (at lines 28-29).

Anyhow, stack ghci works, so everything I need is working with GHC 8 now. I do get a ton of warnings though:

* * * * * * * *
Warning: There are cabal settings for this project which may prevent GHCi from loading your code properly.
In some cases it can also load some projects which would otherwise fail to build.

-XNoImplicitPrelude will be used, but GHCi will likely fail to build things which depend on the implicit prelude.
It is specified for:
    pkb:lib
But not for: 
    pkb:exe:pkb

-XTemplateHaskell will be used, but it may cause compilation issues due to different parsing of '$' when there's no space after it.
It is specified for:
    pkb:lib
But not for: 
    pkb:exe:pkb

-XQuasiQuotes will be used, but it may cause parse failures due to a different meaning for list comprehension syntax like [x| ... ]
It is specified for:
    pkb:lib
But not for: 
    pkb:exe:pkb

-XOverloadedStrings will be used, but it can cause type ambiguity in code not usually compiled with it.
It is specified for:
    pkb:lib
But not for: 
    pkb:exe:pkb

-XTypeFamilies will be used, but it implies -XMonoLocalBinds, and so can cause type errors in code which expects generalized local bindings.
It is specified for:
    pkb:lib
But not for: 
    pkb:exe:pkb

-XGADTs will be used, but it implies -XMonoLocalBinds, and so can cause type errors in code which expects generalized local bindings.
It is specified for:
    pkb:lib
But not for: 
    pkb:exe:pkb

To resolve, remove the flag(s) from the cabal file(s) and instead put them at the top of the haskell files.

It isn't yet possible to load multiple packages into GHCi in all cases - see
https://ghc.haskell.org/trac/ghc/ticket/10827
* * * * * * * *

Despite these warnings, I have not yet noticed any problems :)

@snoyberg

This comment has been minimized.

Copy link
Member

snoyberg commented Nov 24, 2016

Thanks for reporting, I think we can fix that in the scaffolding. Glad it's working now for you, and thanks for testing. Mind if we close this and follow up in the PR itself?

@snoyberg

This comment has been minimized.

Copy link
Member

snoyberg commented Nov 24, 2016

@MaxGabriel Do you think that the ghci wiki page could be changed to just stack ghci? Would there be any downsides?

@SamDM

This comment has been minimized.

Copy link

SamDM commented Nov 24, 2016

As far as I'm concerned, this issue can be closed.

@SamDM

This comment has been minimized.

Copy link

SamDM commented Nov 24, 2016

Maybe one of us should explain the temporary workaround on the stackoverflow question? I can do it if you want but then you won't get any credit for it. Let me know.

@snoyberg

This comment has been minimized.

Copy link
Member

snoyberg commented Nov 24, 2016

Go for it, I'd be much obliged!

@snoyberg snoyberg closed this Nov 24, 2016

@snoyberg snoyberg removed the in progress label Nov 24, 2016

sajith added a commit to sajith/betty-web that referenced this issue Dec 29, 2016

Use `yesod devel`, not `stack exec yesod devel`
See yesodweb/yesod#1304

`stack exec yesod devel` is currently broken, when building with GHC
8.0.1.
@tolysz

This comment has been minimized.

Copy link
Contributor

tolysz commented Jan 17, 2017

I do not have any global ghc only get it via stack.
How yesod devel does it know where ghc is?

Yesod devel server. Type 'quit' to quit
yesod: runghc: readCreateProcess: runInteractiveProcess: exec: does not exist (No such file or directory)
Application can be accessed at:

@snoyberg

This comment has been minimized.

Copy link
Member

snoyberg commented Jan 17, 2017

Which version of yesod-bin are you using (check by running yesod version)? Can you try upgrading to 1.5.1?

@tolysz

This comment has been minimized.

Copy link
Contributor

tolysz commented Jan 17, 2017

It was more about ghc (8.0.2) and it does not fully work if the resolver is not build exactly for the compiler.

It works fine without changing compiler (modulo having to use modified shakespeare which exports Text.Css (Block(..))` so the tycon Block is visible and TH does not panic)

@AshtonKem

This comment has been minimized.

Copy link

AshtonKem commented Feb 4, 2017

I'm seeing this issue on NixOs, but unfortunately the workaround of just using ```yesod devel`` won't work for me because Stack manages the environment on NixOs.

Is there a fix for this that doesn't require me abandon stack?

@snoyberg

This comment has been minimized.

Copy link
Member

snoyberg commented Feb 4, 2017

@AshtonKem

This comment has been minimized.

Copy link

AshtonKem commented Feb 4, 2017

With 1.5.1 I get the following output:

Yesod devel server. Enter 'quit' or hit Ctrl-C to quit.
Application can be accessed at:

http://localhost:3000
https://localhost:3443
If you wish to test https capabilities, you should set the following variable:
  export APPROOT=https://localhost:3443

yesod: stack: startProcess: runInteractiveProcess: exec: does not exist (No such file or directory)
@snoyberg

This comment has been minimized.

Copy link
Member

snoyberg commented Feb 5, 2017

@AshtonKem

This comment has been minimized.

Copy link

AshtonKem commented Feb 5, 2017

Correct. I've been using stack install and stack exec <appname> in the mean time.

Just to narrow it down, stack exec yesod touch also appears to work, so it's something unique to stack exec yesod devel

If you're willing to setup a NixOS VM I can send you my configuration.nix and a sample repo that shows the problem.

@snoyberg

This comment has been minimized.

Copy link
Member

snoyberg commented Feb 5, 2017

That's a pretty big step to take, I'd rather avoid having to set up a VM if I can. I'm pretty sure this is because Stack+Nix plays around with your PATH environment. Can you try running the following:

$(stack exec which yesod) devel

Also, please include the exact commands you run to generate the output you're posting; there's a difference between yesod devel and stack exec yesod devel, for instance.

@AshtonKem

This comment has been minimized.

Copy link

AshtonKem commented Feb 5, 2017

Sorry I wasn't clear, all previous output was done through stack.

I'm a little bit confused on what's happening, I upgraded by stack LTS and the devel command is still broken, but in different ways.

At the risk of confusing you, I'm going to post the several commands I've tried to get devel to work, along with the output. I'm uncertain which way to run devel is the correct way, so please let me know if you need any more info or if you want to move this to a new issue.

$(stack exec which yesod) devel
Executable named which not found on path: ["/home/ashton/Documents/gym/.stack-work/install/x86_64-linux-nix/lts-7.19/8.0.1/bin","/home/ashton/.stack/snapshots/x86_64-linux-nix/lts-7.19/8.0.1/bin","/nix/store/kvjkwch6d466xdmrkjzbh1n6vp573sy8-ghc-8.0.1/bin","/nix/store/91gq1r39y4yfv4k95vl9szw1sg7v9rmg-patchelf-0.9/bin","/nix/store/7m2ch0nyd74y3p8qbzrj3rnz7k81i54v-paxctl-0.9/bin","/nix/store/mwncq6kfcl4iyxr74lihr39fdrghp40q-gcc-wrapper-5.4.0/bin","/nix/store/kgczpyfkh9avarbb1xxi2k2jh5ndyzgw-gcc-5.4.0/bin","/nix/store/2mvblw8kq86ncaidjrp3x4rssy1lhlhi-binutils-2.27/bin","/nix/store/bm052v0zqk8w4gvfwqacszb6b9kijcs4-glibc-2.24-bin/bin","/nix/store/lcwdbh37ha51z86c62mm65vbcfc990dd-coreutils-8.25/bin","/nix/store/lcwdbh37ha51z86c62mm65vbcfc990dd-coreutils-8.25/bin","/nix/store/95vfigaqdg8jg5bk961k1x06j86p5fh0-findutils-4.6.0/bin","/nix/store/222s1mvzd1qipjklq13mrhrjgfngq9fd-diffutils-3.5/bin","/nix/store/c6pcdai9nwd2zmcnbz96j239mgs61qxj-gnused-4.2.2/bin","/nix/store/slrbnmc69dly2gf4by296n32ypsccr0f-gnugrep-2.25/bin","/nix/store/x451jk1q0dadjic52qawhnwfv0f4a4sk-gawk-4.1.3/bin","/nix/store/cj0zinnakxj5zd3fw8050l0ng5mlrwm5-gnutar-1.29/bin","/nix/store/c5y9w08xkiz6kvnscpjv3205gyr6iybz-gzip-1.8/bin","/nix/store/hia247wa09mffcyp66412zg8gliqyw91-bzip2-1.0.6.0.1-bin/bin","/nix/store/zklahbvk9idyjqn6qf667ac1n63yf3s8-gnumake-4.2.1/bin","/nix/store/gabjbkwga2dhhp2wzyaxl83r8hjjfc37-bash-4.3-p48/bin","/nix/store/krskgwnnd18c6wzfwnf0clqqdirpkl1h-patch-2.7.5/bin","/nix/store/5cpnwwnasypdi7p0av6qbaf52y99gmdz-xz-5.2.2-bin/bin"]
devel: command not found

Adding ~/.local/bin to the path only makes NixOS very unhappy, probably something to do with the way that it manages the $PATH variable for you.

stack exec yesod devel
Yesod devel server. Enter 'quit' or hit Ctrl-C to quit.
Application can be accessed at:

http://localhost:3000
https://localhost:3443
If you wish to test https capabilities, you should set the following variable:
  export APPROOT=https://localhost:3443

yesod: stack: startProcess: runInteractiveProcess: exec: does not exist (No such file or directory)

In this case the process immediately exits.

yesod devel
ExitSuccess
Type help for available commands. Press enter to force a rebuild.
Starting devel application
Devel application launched: http://localhost:3000
devel.hs: bind: resource busy (Address already in use)

This one confuses me the most. The devel application starts correctly serves the "Application Isn't Built Yet" on port 3000, but nothing I do will cause it to serve my application. Triggering a build manually (enter or tying "build") sometimes triggers compilation output on the terminal, but my compiled code is never served on port 3000.

@snoyberg

This comment has been minimized.

Copy link
Member

snoyberg commented Feb 7, 2017

Let's focus on that last one. The 3000 port is being successfully bound, but the application's random port assigned by yesod devel cannot be bound. There's no obvious reason for this. I'd recommend:

  • Adding some debug into to devel.hs in your site
  • Running with yesod devel --disable-reverse-proxy to see if it behaves differently
@mrkgnao

This comment has been minimized.

Copy link

mrkgnao commented Feb 21, 2017

@snoyberg
I was in the exact same situation. yesod devel --disable-reverse-proxy worked for me: maybe it's something about the default NixOS firewall/network configuration?

Meanwhile, I can now get started with the Yesod book! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment