ghcjs builds with docker

[Casper Clemence]

I have created a docker image with based on fpco/stack-build with GHCJS installed and known to stack.

I have a project which I am able to build with ghcjs by copying the project into the docker container and running stack build.

However, if I try to build the project locally (with the appropriate docker section added to the stack.yaml) it complains that it can't find the ghcjs compiler.

It is as if it is looking for the compiler locally instead of in the container.

Is the intended behaviour or what am I doing wrong?

Further details:

The Dockerfile I used to build my image was as follows:

FROM fpco/stack-build:lts-7.0
MAINTAINER Casper Clemence  <maninalift@gmail.com>


# install ghcj
COPY "ghcjs/ghc-8.0-2016-09-14-lts-7.0-9007000.tar.gz" "/root/"
ADD ghcjs-build /root/ghcjs-build
RUN cd /root/ghcjs-build && stack setup
RUN rm -rf /root/ghcjs-build


# install Google Closure compiler
RUN sudo apt-get update
RUN sudo apt-get install closure-compiler -y

The tar file is downloaded from http://tolysz.org/ghcjs/ghc-8.0-2016-09-14-lts-7.0-9007000.tar.gz (my starting point has been https://github.com/tolysz/spock-ghcjs-sample).

The directory ghcjs-build contains nothing but a stack.yaml file, the contents of which are:

resolver: lts-7.0
compiler: ghcjs-0.2.0.9007000_ghc-8.0.1
compiler-check: match-exact


setup-info:
  ghcjs:
    source:
      ghcjs-0.2.0.9007000_ghc-8.0.1:
         url: "/root/ghc-8.0-2016-09-14-lts-7.0-9007000.tar.gz"

The stack.yaml for the project itself looks like:

resolver: lts-7.0
compiler: ghcjs-0.2.0.9007000_ghc-8.0.1
compiler-check: match-exact


allow-newer: true


docker:
    enable: true
    repo: "maninalift/stack-ghcjs-build"
    auto-pull: true
   
packages:
- '../project-api/'
- '.'
- location:
     git: https://github.com/agrafix/Spock
     commit: 77333a2de5dea0dc8eba9432ab16864e93e5d70e
  extra-dep: true
  subdirs:
    - Spock-api
    - Spock-api-ghcjs
    - reroute


extra-deps:
- ghcjs-dom-0.3.1.0
- ghcjs-dom-jsffi-0.3.1.0
- rawstring-qm-0.2.2.2

By copying the project into a docker container created from the image maninalift/stack-ghcjs-build and deleting the docker section of the stack.yaml file, I can build the project.

If however I try to build the project locally I get the following error:

No compiler found, expected exact version ghcjs-0.2.0.9007000_ghc-8.0.1 (x86_64) (based on resolver setting in /home/caz/repos/pets/xweb/site/project-frontend/stack.yaml).
Try running "stack setup" to install the correct GHC into /home/caz/.stack/programs/x86_64-linux-dk3a4ba5cbb06b149b5ecd98e80c865100/

Am I just misunderstanding the design of stack when I expect it to detect ghcjs inside the docker container? I'd really like users of the repository to be able to download the docker image and start building the project without building ghcjs.

Thank you all for your attention.

[Casper Clemence]

p.s.

stack --version                                                                                                       :(
Version 1.2.0 x86_64 hpack-0.14.0

[Michael Snoyman]

My guess would be that, in your Dockerfile, you're setting this up as the root user, inside a root-user-specific directory. But from `stack build`, it's running it as your host system user, which doesn't have access to the root home directory's files. Perhaps playing with the PATH would help, but I'm not sure what the best approach is in this case to be honest.

--
You received this message because you are subscribed to the Google Groups "haskell-stack" group.
To unsubscribe from this group and stop receiving emails from it, send an email to haskell-stack+unsubscribe@googlegroups.com.
To post to this group, send email to haskel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-stack/0d692ef4-d81e-43e4-b8ed-a6a2233a190c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Shane Pearlman]

What do you know about the behavior of the `compiler` flag?  When working with a non-ghc compiler (and not in the snapshot), what exactly is happening with the version check?

I've been wanting to do this as well... The simplest solution I can imagine is to escape Stack's desire to handle installation of the compiler, for example:

```
compiler: ghcjs
setup-info:
  ghcjs:
    manual: true
    path: /usr/bin/ghcjs
```

The main thing is he's trying to remaster the container, so there shouldn't be any dependence on the host or user that will use the container.  Another related idea is to allow manual specification a location for the snapshot dir, like:

```
snapshot-override:
- lts-7.0:
  /opt/stackage/lts-7/snapshot
```

That would allow easy remastering of the fpco containers by simply running a stack build for some big lib, at the expense of snapshot sharing on the host machine.  Actually, is there any way that Stack's model could be extended to allow sub-layering of snapshots? Well, even without it, I think the option to store your shared snapshot in the container would be very helpful.

Michael, actually my initial purpose for remastering was to create a yesod container!

On Thursday, September 22, 2016 at 12:19:01 AM UTC-7, Michael Snoyman wrote:

My guess would be that, in your Dockerfile, you're setting this up as the root user, inside a root-user-specific directory. But from `stack build`, it's running it as your host system user, which doesn't have access to the root home directory's files. Perhaps playing with the PATH would help, but I'm not sure what the best approach is in this case to be honest.

On Wed, Sep 21, 2016 at 11:44 AM, Casper Clemence <manin...@gmail.com> wrote:

p.s.

stack --version                                                                                                       :(
Version 1.2.0 x86_64 hpack-0.14.0

--
You received this message because you are subscribed to the Google Groups "haskell-stack" group.

To unsubscribe from this group and stop receiving emails from it, send an email to haskell-stac...@googlegroups.com.

To post to this group, send email to haskel...@googlegroups.com.

[Casper Clemence]

Thank you both for your replies. Sorry for being slow on my own thread, this project has taken a back seat for a while. 

The approach I was thinking of taking to solve this problem was to create a new user inside the container when setting up the container and run as this user

when running the ghcjs setup then to ask docker to run with this user using he docker parameters in the stack file. I'm guessing however it might not be as

simple as this as the file ownership might not work out without some work.

Casper

[Shane Pearlman]

Yeah, that could be messy.  It really seems like these are some things Stack needs to support better.  It feels like the machinery is 99% of the way there, and with a little polish around the corner cases, this could be a really flexible workflow.