Add elixir_make workaround

[codyps]

If we don't set ELIXIR_MAKE_CACHE_DIR, the elixir_make package attempts to write to a cache directory under $HOME, which fails.

Get many of the elixir_make items working by adding this and adding gnumake as a build input.

For some elixir_make packages, they'll still need additional depenencies, which can be added on a package name basis.

Note: It feels like this and rustlerPrecompiled, which both examine dependencies to decide on workarounds could potentially be done purely in nix instead of examining the dependencies in the deps_nix code. Doing that would also make it more clear to others how to add local workarounds for all crates that depend on a particular crate. I've kept this in deps_nix's elixir code for now for consistency with rustlerPrecompiled.

Note also: this doesn't apply both workarounds if a package depends on both rustler_precompiled and elixir_make, it prefers applying the rustlerPrecompiled workaround if rustler_precompiled is depended on. We could apply the workarounds in series, but I'm not sure that would make sense, and in practice packages tend to either depend on rustler_precompiled or elixir_make and not on both.

[camelpunch]

Thanks for the PR. Part of the reason I moved the logic into Elixir was to make exceptional cases easier to test. Could you please add some tests that would fail if this feature wasn't implemented, or regressed?

I don't mind figuring out the tests if you prefer.

[camelpunch]

I hear you on the ease-of-contribution issue: I think a restructuring to make it more obvious how to add a package that's expected to work could help here. I'll think about it.

[camelpunch]

It turns out that elixir_make's been building for a while, as have some packages that use it (vix, cc_precompiler). I guess this is an issue with certain dependencies that use elixir_make? Would you mind sharing which packages have problems?

[codyps]

It turns out that elixir_make's been building for a while, as have some packages that use it (vix, cc_precompiler). I guess this is an issue with certain dependencies that use elixir_make? Would you mind sharing which packages have problems?

Here's a self contained repo showing the failure by depending on exqlite, which uses elixir_make internally: https://github.com/codyps/deps_nix_elixir_make

Here's the nix build output for that repo showing the same kind of failure I've seen in other larger projects:

cody@u3 deps_nix_elixir_make % nix build
error: Cannot build '/nix/store/482jw4qnri9wd92hf2790h3j8254zd2l-exqlite-0.33.0.drv'.
       Reason: builder failed with exit code 1.
       Output paths:
         /nix/store/h5qyqsjmy6gwhl9qmjzw1bxx8ajypkif-exqlite-0.33.0
       Last 15 log lines:
       > Running phase: unpackPhase
       > unpacking source archive /nix/store/vrhzizxqdxfhr484wn2mk1l8n3s782s8-exqlite-0.33.0
       > source root is exqlite-0.33.0
       > Running phase: patchPhase
       > Running phase: configurePhase
       > Running phase: buildPhase
       > ** (File.Error) could not make directory (with -p) "/homeless-shelter/Library/Caches/elixir_make": no such file or directory
       >     (elixir 1.18.3) lib/file.ex:346: File.mkdir_p!/1
       >     (elixir_make 0.9.0) lib/elixir_make/artefact.ex:22: ElixirMake.Artefact.cache_dir/0
       >     (elixir_make 0.9.0) lib/elixir_make/artefact.ex:85: ElixirMake.Artefact.archive_path/3
       >     (elixir_make 0.9.0) lib/mix/tasks/compile.elixir_make.ex:226: Mix.Tasks.Compile.ElixirMake.download_or_reuse_nif/3
       >     (elixir_make 0.9.0) lib/mix/tasks/compile.elixir_make.ex:169: Mix.Tasks.Compile.ElixirMake.run/1
       >     (mix 1.18.3) lib/mix/task.ex:495: anonymous fn/3 in Mix.Task.run_task/5
       >     (mix 1.18.3) lib/mix/tasks/compile.all.ex:117: Mix.Tasks.Compile.All.run_compiler/2
       >     (mix 1.18.3) lib/mix/tasks/compile.all.ex:97: Mix.Tasks.Compile.All.compile/4
       For full logs, run:
         nix log /nix/store/482jw4qnri9wd92hf2790h3j8254zd2l-exqlite-0.33.0.drv
error: Cannot build '/nix/store/s6sjz3wks7f0vsjahd33i0bki30x0667-deps_nix_elixir_make-0.0.0.drv'.
       Reason: 1 dependency failed.
       Output paths:
         /nix/store/pbnh4cil7j6a97pv1d864h23dzkafwfx-deps_nix_elixir_make-0.0.0

vix works because deps_nix includes a vix-specific workaround that causes vix to avoid invoking the elixir_make code at all (by setting VIX_COMPILATION_MODE). I'm not sure if cc_precompiler works. It depends on ElixirMake, so I suspect it won't if it triggers the elixir_make code.

Edit: on second thought, I'm not sure why vix works. I'd expect to see it still have issues because it still needs to build some c code, just not libvips itself.

(yes, for exqlite specifically I can use a specific override for exqlite to have it behave like vix with the override, but it seems preferable that everything work and then we can add specific package handling as needed)

[camelpunch]

Thanks for going to the trouble of making a reproduction repo!

In future, you can add packages to the deps_nix suite like this:

cd fixtures/example
# edit mix.exs to add your dependency
mix deps.get
mix deps.nix
nix build .#name_of_dependency

I did this on main for exqlite and it does reproduce the error.

Would you mind including exqlite in fixtures/example/mix.exs and the associated deps.nix change as part of this PR?

[codyps]

Thanks for pointing me in the right direction here. I've added the changes to ensure exqlite builds, and fixed the breakage to the vix test due to adding this (we may want to consider if we might want to tweak the override generation so it doesn't apply to the vix special case)

[camelpunch]

It looks like this is breaking the vix build. Would you mind taking a look?

[tjarratt]

Having a look at this, I think I see what happened. When we apply the elixir_make workaround for lazy_html, that applies to vix (because it depends upon elixir_make), and since our override sets the nativeBuildInputs for the derivation, the ones we had previously set for vix end up getting overriden.

I think I see a few ways to handle this, I'll take a pass at it.