stack new with ghcjs template doesn't initialize correctly

[kadoban]

Using the ghcjs template with stack new doesn't really get you very far.

Command: stack new testing ghcjs

Expected result: A project set up named testing which will use the GHCJS compiler support that's been so helpfully added somewhat recently.

Perhaps including something in the stack.yaml like the magic:

compiler: ghcjs-0.1.0.20150924_ghc-7.10.2
compiler-check: match-exact

would be ideal.

Actual result:

Downloading template "ghcjs" to create project "testing" in testing/ ...
Writing default config file to: /home/mud/projects/testing/stack.yaml
Basing on cabal files:
- ~/projects/testing/testing.cabal

Checking against build plan lts-3.12

* Build plan did not match your requirements:
    ghcjs-base not found
    - testing requires -any

[... several more build plans fail to match ...]

There was no snapshot found that matched the package bounds in your .cabal files.
Please choose one of the following commands to get started.

    stack init --resolver lts-3.12
[... more resolver possibilities suggested ...]

You'll then need to add some extra-deps. See:

    https://github.com/commercialhaskell/stack/blob/release/doc/yaml_configuration.md#extra-deps

You can also try falling back to a dependency solver with:

    stack init --solver

and no stack.yaml at all is created in the testing/ directory.

I think I understand why this happens, but is there any way to improve the workflow here? It would be really nice to be able to start a GHCJS project easily with stack new.

Note that none of the suggested init commands give you anything that will use GHCJS, and specifying --resolver lts-3.14 for example to stack new doesn't either (though that will at least make it create a stack.yaml file, which is something).

Version:

$ stack --version
Version 0.1.8.0, Git revision e33dd995e292efcf8ee42e1e4c649b96232abf2e (2603 commits) x86_64

[mgsloan]

Thanks for the detailed issue! Indeed, I'm aware of the problem and should have created an issue for this. One issue is that many packages are buildable with both GHC and GHCJS - there isn't the metadata to ensure that it should be initialized as a GHCJS project.

Here's some old WIP changes I had to resolve this https://gist.github.com/mgsloan/e50dcf2318347a050fe5 . The commented out approach was to look for impl(ghcjs) and assume its presence means its a GHCJS project. The other approach is to try resolving the package configuration and check if it's buildable with GHCJS but not GHC, which seems like the right thing to do.

Quite a bit of hassle just to get stack init behaving right. Maybe it'd be better for the templates to have some flags to pass into init, and add a --ghcjs flag.

I've got other fish to fry right now - PRs welcome

[kadoban]

I've been thinking about this off and on a bit, some thoughts:

• Would it be possible for templates to just specify some parts of stack.yaml? It could then be combined with what stack new would otherwise want to throw in there. Then all the ghcjs template would have to include would be the compiler: line(s).

  If necessary maybe the templates could be restricted to a whitelisted subset of allowed content to throw in stack.yaml, though I can't specifically think of anything dangerous to put in there anyway, especially considering that an evil template could already just throw some TH in any of the created .hs files to do arbitrary IO actions, so it doesn't seem to add any new attacks or anything.

  The only kind of difficult part is then trying to combine the stack.yaml from the template with what stack init does in the case when they both define conflicting options (like both try to set the resolver or whatever). Not really sure how to deal with that, or could possibly see just ignoring it and saying "don't do that" (or the whitelist could be useful here too, just don't allow anything the normal init would want to do).

• The --ghcjs flag sounds interesting for stack init and stack new related things, and I think that'd be a great little feature to have, but I'm not clear on how that could even work in principle. How can stack figure out what version of the GHCJS compiler to use? Is there some way to query the possible ones even? Would one have to be hardcoded corresponding to each major GHC version?

[mgsloan]

Would it be possible for templates to just specify some parts of stack.yaml? It could then be combined with what stack new would otherwise want to throw in there.

Certainly a reasonable idea. I don't think we're going to do stack.yaml configuration inheritance in general (#1375), but we could certainly consider supporting some subset of the fields for this purpose.

The --ghcjs flag sounds interesting for stack init and stack new related things, and I think that'd be a great little feature to have, but I'm not clear on how that could even work in principle. How can stack figure out what version of the GHCJS compiler to use? Is there some way to query the possible ones even? Would one have to be hardcoded corresponding to each major GHC version?

The only "official" version of GHCJS as far as stack is concerned is 0.1.0, a.k.a. old base. The list is here: https://github.com/fpco/stackage-content/blob/master/stack/stack-setup-2.yaml#L221

It is true that it'll be tough to pick a GHCJS version, because we don't have stackage snapshots that contain info about packages like ghcjs-base. Picking the most recent GHCJS seems pretty reasonable, particularly when building packages usually intended for GHC. Another wrinkle is that since the stackage snapshots don't contain ghcjs specific packages, init and new will fail to find a resolver that works (unless they use --solver).

It should be possible to resolve this stuff once GHCJS and related packages get uploaded to hackage and added to stackage (one way or another).

[nrolland]

"It should be possible to resolve this stuff once GHCJS and related packages get uploaded to hackage and added to stackage (one way or another)."

Are there any public timeframe for this ?

[mgsloan]

Nope, hopefully soon, but I have no idea.

[kuznero]

Is there any workaround to this problem?

[snoyberg]

The next version of Stack will no longer have GHCJS support, closing.