I'm not sure if I need to take any further action regarding the CI failure? It seems unrelated to this change, but I could definitely be wrong

Looks like an unrelated evaluation error on master at the time; let's try again.

@GrahamcOfBorg eval

I'm not in favor of this, there are a lot of known problems when the LS is running on a different elixir version than what was used to compile.

The precompiled version is compiled using Elixir 1.8 as you can see here:

https://github.com/elixir-lsp/elixir-ls/blob/master/.release-tool-versions#L6

This version, when used with a runtime Elixir of 1.10, is known to cause problems with completing names that are in scope due to macro expansion.

I have a derivation in my personal overlay that seems to work reliable.

I have to admit though, that this derivation, as well as the helper function is largely inspired by some code of the user @hauleth.

• the derivation: https://gitlab.com/NobbZ/nix-home-manager-dotfiles/-/blob/master/nix/myOverlay/elixir-lsp/default.nix
• the helper function: https://gitlab.com/NobbZ/nix-home-manager-dotfiles/-/blob/master/nix/myOverlay/elixir-lsp/fetch-mix-deps.nix

@NobbZ if you want to open a PR that's more robust than this I'm happy to close this in favour of a better solution

@NobbZ I took a look at the implementation of fetch-mix-deps you're using. Given the amount of work that's gone into solving this problem (here and here) my gut feeling is that fetch-mix-deps isn't going to be pure enough to make it into nixpkgs. I completely agree building from source, especially building from source with a version of elixir that matches that in nixpkgs, would be a far better solution. As it stands right now there just isn't a good reproducible way to fetch elixir dependencies with nix to make that happen.

That said I think a good compromise would be to fork the elixir-ls repo, and generate releases for the language server using the same version of elixir that is currently in the store. Others feel free to voice your opinions on that though, I'm far from an expert on nix and maybe there is a better solution I'm not seeing

Given the amount of work that's gone into solving this problem (here and here) my gut feeling is that fetch-mix-deps isn't going to be pure enough to make it into nixpkgs.

As an author of that script I can say a little about it. Right now the approach I took is only safe way to fetch deps. By safe I mean that it is future proof, as Mix do not have any guarantees about mix.lock format, we cannot parse that file reliably. But if we assume that mix.lock is present in the repo, and we know it hash, then mix guarantee that it will be constant (reproducible) output (that is the whole idea of lock files in the first place), however I am not sure how it will behave in case of updated Hex releases, but these have so small window that it shouldn't be a problem. So this one should work in Nix-compatible way.

The only problem we ever had with that function was when an update of hex introduced a second hash value into the lock file and mix insisted on "repairing" the lock file for use which was in the old version. This again failed as mix.lock was read-only.

And I was pretty sure we reported it as a bug and asked for at least not failing if mix.lock can't be written to when runnings a deps.get, though I currently can't find the issue neither at the elixir, nor the hex repo.

In that case I stand corrected, should this then be something that is merged into nixpkgs? I know I would personally really enjoy having a way to fetch hex dependencies the nix way, and I'm sure there are many others that are unaware of this solution

I have even started the repo for such functions - https://github.com/hauleth/nix-elixir, however I didn't have time to improve that recently. I will need to sit and fix that. Unfortunately I do not see a way to make overrides to beam.packagesWith, which would make it even better. Maybe there is some way that I am not aware of.

I have updated my repo with overlay. Now it can be mostly copied to the NixPkgs almost as is. It adds support for ElixirLS, ErlangLS and Sourcer as well as adding fetchMixDeps and buildMix' derivation builders.

I have updated my repo with overlay. Now it can be mostly copied to the NixPkgs almost as is. It adds support for ElixirLS, ErlangLS and Sourcer as well as adding fetchMixDeps and buildMix' derivation builders.

Do you plan to contribute these? It might be useful to get the conversation going as the elixir infra in nixpkgs needs some love. I do know that there's a crowd that prefer the lockfiles to be turned into deps.nix files https://github.com/nix-community/vgo2nix, and then there's the method you use here which has some downsides (just look at some of the rust issues we've had to now create https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/rust/fetchCargoTarball.nix).

I'm happy to contribute if necessary, but it does seem more appropriate for the author to contribute @hauleth. Not to mention I don't think I'm knowledgeable enough to be the maintainer

@Parasrah Oh sorry, I should have @'d @hauleth. That response was meant for them, I can understand you assumed it was because this is your thread/PR.

Sorry didn't mean to give the impression I thought the response was for me. I just wanted to clarify my position in case nobody else wants to add / maintain those utilities

I've since tried testing this out myself. Note this is just a quick hacky attempt, I don't know that we can replace buildMix, not sure if this is the desired directory structure and I know the commit message isn't correct. I'm finding this isn't actually working though? I'm getting the following error:

installing 'elixir-ls-e50e153977af83238f196f0ab0c5aa0156c7573f'
these 2 derivations will be built:
  /nix/store/j8rq1m1nmfqmhcm758f2lfw4q8wnydyg-elixir-ls-e50e153977af83238f196f0ab0c5aa0156c7573f-deps.drv
  /nix/store/37960611xa9mxgjhbh3v2acv8v4jrnh4-elixir-ls-e50e153977af83238f196f0ab0c5aa0156c7573f.drv
building '/nix/store/j8rq1m1nmfqmhcm758f2lfw4q8wnydyg-elixir-ls-e50e153977af83238f196f0ab0c5aa0156c7573f-deps.drv'...
unpacking sources
unpacking source archive /nix/store/qvjs8m34anvnj0g8vivy9sdarp5rypbx-source
source root is source
patching sources
configuring
building
* Getting elixir_sense (https://github.com/elixir-lsp/elixir_sense.git)
fatal: unable to access 'https://github.com/elixir-lsp/elixir_sense.git/': Could not resolve host: github.com
** (Mix) Command "git --git-dir=.git fetch --force --quiet --progress" failed
error: --- Error --- nix-daemon
builder for '/nix/store/j8rq1m1nmfqmhcm758f2lfw4q8wnydyg-elixir-ls-e50e153977af83238f196f0ab0c5aa0156c7573f-deps.drv' failed with exit code 1; last 9 log lines:
  unpacking sources
  unpacking source archive /nix/store/qvjs8m34anvnj0g8vivy9sdarp5rypbx-source
  source root is source
  patching sources
  configuring
  building
  * Getting elixir_sense (https://github.com/elixir-lsp/elixir_sense.git)
  fatal: unable to access 'https://github.com/elixir-lsp/elixir_sense.git/': Could not resolve host: github.com
  ** (Mix) Command "git --git-dir=.git fetch --force --quiet --progress" failed

Not sure why this is? Fixed output derivations aren't being phased out as part of flakes are they or something like that? I do have flake support turned on

Side note: this whole thing prompted me to learn about fixed output derivations, and my apologies for my previous stance

my gut feeling is that fetch-mix-deps isn't going to be pure enough to make it into nixpkgs

I was clearly uninformed

From first glance it seems as if you have missed to pass the sha. If you leave it out, then buoldMix will operate in "no sandbox" mode and try to download anyway. Once you pass in a sha256, it will be FOD.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/state-of-the-beam-ecosystem-in-nix/4202/15

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/whats-the-current-best-in-class-approach-to-packaging-elixir-erlang-beam-applications-using-nix-releases-as-of-july-2020/8205/11