Reduce Elm closure

[domenkozar]

It's around 1400MB atm: http://hydra.nixos.org/job/nixos/trunk-combined/nixpkgs.elmPackages.elm-compiler.x86_64-linux#tabs-charts

[vcunat]

I suspect most of it is Haskell #4504.

[domenkozar]

I tried setting enableSharedExecutables = false; on each elm package, but that didn't yield much result.

[vcunat]

I guess it needs to compile haskell during runtime.

[domenkozar]

Don't think so, npm has binary compiled elm in 80M:

$ du -sh node_modules/elm/Elm-Platform/0.17.0/.cabal-sandbox/bin/
78M     node_modules/elm/Elm-Platform/0.17.0/.cabal-sandbox/bin/

All statically compiled

[vcunat]

OK, sounds convincing. If it doesn't assume ghc on $PATH or something.

[peti]

@domenkozar, enableSharedExecutables = false; helps only for packages that have no library components. Once a package provides a library, it invariable depends on the transitive closure of its dependencies -- which includes GHC. If the libraries aren't neeed by end-users, then it might make sense to remove them to mitigate this problem.

[domenkozar]

@peti indeed.

I can get it down from 1.7G to 50MB using following patch:

diff --git a/pkgs/development/compilers/elm/packages/elm-compiler.nix b/pkgs/development/compilers/elm/packages/elm-compiler.nix
index f6a92b6..d1c0171 100644
--- a/pkgs/development/compilers/elm/packages/elm-compiler.nix
+++ b/pkgs/development/compilers/elm/packages/elm-compiler.nix
@@ -13,8 +13,10 @@ mkDerivation {
     sha256 = "17y0jlii81mnjywknblcv1nfja51slmwrhz9x8w144b0sblcj0if";
     rev = "e44deafaf9cbf3749484070f267f03a368711adb";
   };
-  isLibrary = true;
+  isLibrary = false;
   isExecutable = true;
+  enableSharedLibraries = false;
+  enableSharedExecutables = false;
   libraryHaskellDepends = [
     aeson aeson-pretty_0_7_2 ansi-terminal ansi-wl-pprint base binary
     bytestring containers directory edit-distance filepath indents

But elm-make and others can't be compiled then since elm-compiler library doesn't exist. Does that mean we have to build elm-compiler twice?

[peti]

If the elm library is required to compile elm programs, then it seems like elm compilation implies Haskell compilation, which in turn requires GHC and friends. I don't see what we could do about that, really (except for some multiple outputs magic).

[domenkozar]

@peti it's not required to compile Elm programs, but to compile all of Elm executables (elm-make, elm, etc).

[peti]

Hmm, in that case you would probably need a full version of elm for compiling the toolchain, and the toolchain itself would then be linked statically so that nothing refers to GHC. I am sorry for being vague, but I know nothing about elm and its internal structure, so I have really no clue what I am talking about here. 😄

[domenkozar]

There is now upstream discussion to join all projects under Elm: https://groups.google.com/forum/#!topic/elm-dev/-qGgYTKyAS8

Until this is decided I don't think it's worth pursuing reducing closure size, but let's keep the issue open as a reminder to myself to check this in a few months.

[domenkozar]

0.19 is going to be great for us and allow really simple change to achieve this: https://groups.google.com/forum/#!topic/elm-dev/qdu3NqOqGrY

[domenkozar]

I'm going to close this, Elm 0.19 ships a single executable so it will be easy to use static haskell dependencies for compiling it with small closure-size.

[domenkozar]

Elm 0.19 should have been released a long time ago.

Once #32082 is done, we can really just do enableSharedExecutables = false; as I intended a year and a half ago.

[domenkozar]

Fixed by f73e524 once #32629 is going to be merged.

[arianvp]

Elm 0.19 has just been released!

[domenkozar]

See #45448