DISCUSSION: Mark GHCJS support as deprecated?

[snoyberg]

From what I can tell:

• The GHCJS codepaths are not currently being actively maintained in Stack
• Most of the GHCJS community recommends Nix for setting up the toolchain
• None of the regular Stack contributors are using the GHCJS support

Given this, I'd recommend in the next major release of Stack to mark GHCJS support as deprecated and begin printing warnings when it's used. We can later worry about when, if ever, we actually remove the support.

Another possibility could be to only remove support for installing GHCJS itself, but retain the ability to build with it.

[mgsloan]

Another possibility could be to only remove support for installing GHCJS itself, but retain the ability to build with it.

I'm in favor of this approach. IIRC the code for using ghcjs to build is quite small and so not a big maintenance burden, but the code for installing ghcjs is complicated and error prone. Considering that stack setup for ghcjs can take a long time, it seems sensible to encourage users to find a different approach to installation, perhaps involving prebuilt binaries.

[borsboom]

When I last tried the GHCJS support in the fall, it was very frustrating to get working. Documentation was incomplete and out of date, there didn't seem to be a good way to get it to work with recent GHC versions or Stackage snapshots, and it all just felt very hacky because you needed these special GHCJS distributions with specific versions of base packages that were difficult to generate. To be fair, a big part of this is the fact that there wasn't any release process for GHCJS versions, it just seemed to be in perpetual development. I'd be in favour of deprecating unless some real effort is put into making this more usable.

[bitemyapp]

How's a warning that'll usually get triggered at the start?

$ /home/callen/work/stack/.stack-work/install/x86_64-linux/lts-11.6/8.2.2/bin/stack build
Building a GHCJS project. Note that GHCJS support in Stack is DEPRECATED and it will be removed  in a future release of Stack.
miso-0.21.1.0: unregistering (flags changed from ["-fexamples","--ghcjs"] to ["--ghcjs"])
miso-0.21.1.0: configure (lib)
Configuring miso-0.21.1.0...
miso-0.21.1.0: build (lib)
Preprocessing library miso-0.21.1.0...
[... snip ...]
[34 of 34] Compiling Miso             ( ghcjs-src/Miso.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0_ghcjs/build/Miso.js_o )
miso-0.21.1.0: copy/register
Installing library in
/home/callen/work/miso/.stack-work/install/x86_64-linux/lts-6.20/ghcjs-0.2.0.9006020_ghc-7.10.3/lib/x86_64-linux-ghcjs-0.2.0.9006020-ghc7_10_3/miso-0.21.1.0-2K9hamfIcJSIhYT9IvbE75
Registering miso-0.21.1.0...

I'll put up a PR, you can tell me if you want it to spit a warning at the end or not.

[gleachkr]

For what it's worth, I use stack and ghcjs together for a couple of client-server projects. I believe @matchwood is working on creating some ghcjs tarballs for more recent resolvers at https://github.com/matchwood/ghcjs-stack-dist. I understand the arguments above, but I'd be sad to see ghcjs support go.

[matchwood]

Only just seen this, thanks for the heads up @gleachkr !

@snoyberg I think your three points are quite closely related, and really come down to the last one: "None of the regular Stack contributors are using the GHCJS support".

The move to nix seems (to me) at least partially because of the patchy support for ghcjs offered by stack. But deprecating support, rather than improving it, is a rather sad backward step. Haskell is a hard enough sell by itself, ghcjs doubly so, but then adding in a requirement to master nix just to get a working compilation environment seems to be consigning ghcjs to the margins of usability. Which would be a great shame, given the potential promise of end-to-end type safety, code reuse, etc etc in client server applications.

As @gleachkr mentioned, I have put together tarballs for a couple of resolvers, and while it is a somewhat tedious and slow process it is not inherently very difficult.

On a related note, when experimenting with more recent ghcjs versions (ghc 8.2) I struggled to get stack to even build anything with a separately installed compiler, so some changes will probably have to be made to the build code as well as the setup code.

In the next few weeks I was planning to spend some time getting a working ghcjs 8.2 tarball together, and as part of that I will almost certainly have to make some changes to stack, so it might be worth holding off on this issue to give me chance to look at the current code. In principle I would be interested in committing to developing and supporting ghcjs support in stack, but at present I can't make any promises.

[dbaynard]

while it is a somewhat tedious and slow process it is not inherently very difficult.

It's good to hear this isn't very difficult. It's unfortunate, though, that it is slow and tedious. @matchwood what would be needed to change that?

I migrated code away from ghcjs because of tooling issues, like installing the compiler (this was back when arch and nix weren't playing nicely). I was having some joy with @matchwood's tools, actually. But it was too haphazard, and a key project requirement was ease of building the frontend. Unless much has changed (and "I struggled to get stack to even build anything with a separately installed compiler" suggests not) ghcjs is unsupported in stack, and I would argue stack should tell users that.

Moving forward: I've just come across haskell/process#128, which includes a very long comment about the business need for ghcjs (from two months ago). The author of ghcjs then followed up, essentially saying that the project is not ready for patches to boot libraries to be pushed upstream. I haven't found any indications of when it may reach this point. Is there a roadmap for ghcjs?

[silky]

just to throw an annoying vote in; i'd love to stack to support ghcjs somehow.

echoing others, i really can't be bothered getting nix to work; it's a bridge a bit too far, and i was really excited to see this from matchwood https://github.com/matchwood/ghcjs-stack-dist ; so i'd love to see ghcjs become much more easy to work with. seems like stack is a nice way to go here. but i can imagine it may require a heap of effort on stack's part.

a particularly amusing recent somewhat-related work here is this: https://github.com/nomeata/ghcjs2gh-pages by @nomeata; note that it doesn't use stack at all! the travis.yml is comically complicated.

[RobertFischer]

I am also willing to throw in for GHCJS support. On Jul 16, 2018 7:43 PM, "Noon van der Silk" <notifications@github.com> wrote: just to throw an annoying vote in; i'd love to stack to support ghcjs somehow. echoing others, i really can't be bothered getting nix to work; it's a bridge a bit too far, and i was really excited to see this from matchwood https://github.com/matchwood/ghcjs-stack-dist ; so i'd love to see ghcjs become much more easy to work with. seems like stack is a nice way to go here. but i can imagine it may require a heap of effort on stack's part. a particularly amusing recent somewhat-related work here is this: https://github.com/nomeata/ghcjs2gh-pages by @nomeata <https://github.com/nomeata>; note that it doesn't use stack at all! the travis.yml is comically complicated. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#4086 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABO1404_B1UeZqTk0wxHTi4C-i4zCaIks5uHSUEgaJpZM4UngEW> .

[nomeata]

note that it doesn't use stack at all! the travis.yml is comically complicated

I'd say that's mostly in order to work around resource constraints on Travis