Nix all the things

[commandodev]

I've replaced haste with ghcjs specfic stuff in .cabal and added a shell.nix and a default.nix.

If you have a checkout of nixpkgs you should be able to run:

⇒  nix-shell -I . --pure # I have a symlink to my checkout of nixpkgs in cwd                           

[nix-shell:~/dev/ghcjs/react-haskell]$ cabal configure --ghcjs
Warning: The package list for 'hackage.haskell.org' is 247.0 days old.
Run 'cabal update' to get the latest list of available packages.
Resolving dependencies...
Configuring react-haskell-1.3.0.0...

[nix-shell:~/dev/ghcjs/react-haskell]$ cabal build
Building react-haskell-1.3.0.0...
Preprocessing library react-haskell-1.3.0.0...

src/React/Anim.hs:9:8:
    Could not find module ‘Haste’
    Use -v to see a list of the files searched for.

src/React/Attrs.hs:6:8:
    Could not find module ‘Haste.JSON’
    Use -v to see a list of the files searched for.

src/React/Attrs.hs:7:8:
    Could not find module ‘Haste.Prim’
    Use -v to see a list of the files searched for.

src/React/Imports.hs:12:8:
    Could not find module ‘Haste.Foreign’
    Use -v to see a list of the files searched for.

src/React/Interpret.hs:6:8:
    Could not find module ‘Haste.DOM’
    Use -v to see a list of the files searched for.

So this seems to drop you into a sane nix-shell sans all the implementation changes you'd have to make to use ghcjs instead of haste :-)

[joelburget]

Thanks :) Going to leave this open for now, until I get a chance to look at the GHCJS stuff.

[commandodev]

Sure thing. Leaving out the cabal changes could probably be made to work
for haste too, so give me a shout if you want to explore nix without ghcjs.
:-)
On 10 Feb 2015 21:58, "Joel Burget" [email protected] wrote:

Thanks :) Going to leave this open for now, until I get a chance to look
at the GHCJS stuff.

—
Reply to this email directly or view it on GitHub
#19 (comment)
.

[joelburget]

By the way, why did you symlink your nixpkgs to the current directory? Is that a typical way of working?

[commandodev]

That's the way I do it. I like to have -I . so that you can symlink both
local packages under development and nixpkgs in one go. You can install
nixpkgs to a path globally (I think in ~/.nix-something) but I think is
more flexible as you can point different projects at different nixpkg
versions (e.g. for ghcjs).

On 28 February 2015 at 19:20, Joel Burget [email protected] wrote:

By the way, why did you symlink your nixpkgs to the current directory? Is
that a typical way of working?

—
Reply to this email directly or view it on GitHub
#19 (comment)
.

Regards,
Ben Ford
[email protected]
+447540722690

[AphonicChaos]

Pardon me if I'm being daft, @Boothead , but this simply exposes react-haskell to nix, doesn't force it's usage, right?

[commandodev]

You are correct @Aspidites. Nothing is forced, just consider it a strong hint ;-)