@gleber, thanks for your PR! By analyzing the history of the files in this pull request, we identified @ericbmerritt and @LnL7 to be potential reviewers.

from IRC:

gleber_: Does that actually change anything? nix-review claims nothing changed.
<gleber_>: Ankhers: it does not change anything among top-level packages, but it does introduce many packages, which are not "exported"
<gleber_>: Ankhers: that's also one thing that I'd like to get feedback on. Is this really useful to have such "non-exported" packages defined at all? Should they be "exported"? Does this apply to only binaries, or to libraries too?

Just glancing at this on my phone for now, but does it enable easy building of arbitrary Hex packages as dependencies (and injecting them into beam.packages or whatever)? That's something I've wanted for a while.

@yurrriq I think it does provides some parts of what you want:

• beam.packages.erlangRXX.buildHex makes it easy to build a package from Hex;
• beam.packages.erlangRXX contains many packages from Hex (although this list is very outdated as you know).

There is no nice mechanism to do beam.packages.erlang.override to actually inject new packages into this package set, but it is probably not hard to add.

@LnL7 @ankhers @ericbmerritt This PR is ready to be reviewed.

Rebased, fixed all comments (by addressing them in appropriate commits, hence commit ids have changed).

nox-review passed on OSX.

Current state of PR built successfully built on NixOS with sandboxes:

$ nix-shell -p nox --run "nox-review pr 26668"
...
Result in /run/user/1000/nox-review-982bk1l1
total 0
lrwxrwxrwx 1 gleber users 57 Jun 19 20:36 result -> /nix/store/lnxk39nmhg03pi5lniz3v8kih6vz0sxa-hex2nix-0.0.5
lrwxrwxrwx 1 gleber users 56 Jun 19 20:36 result-2 -> /nix/store/4npkcs2ds1dga0903mjbvj4ya3h3rq77-rebar3-3.3.2
lrwxrwxrwx 1 gleber users 59 Jun 19 20:36 result-3 -> /nix/store/mfdf6z2hjxpyk1rrnj0knpzxxdnrmlva-relx-exe-3.18.0
lrwxrwxrwx 1 gleber users 53 Jun 19 20:36 result-4 -> /nix/store/wx7bvpfimz0n68dkgjkai0kajxsx1h0a-lfe-1.2.1
lrwxrwxrwx 1 gleber users 56 Jun 19 20:36 result-5 -> /nix/store/n3j5kw7glc12g9gdvj83h39airmfinp1-rebar3-3.3.2
 1

This is working great for me, but I want to use erlangR19 globally and I feel like this override is wrong or a bit clunky:

{
  nixpkgs.config.packageOverrides = pkgs: rec {
    beam = pkgs.beam // rec {
      interpreters = pkgs.beam.interpreters // {
        erlang = pkgs.beam.interpreters.erlangR19;
      };
      packages = pkgs.beam.packages // {
        erlang = pkgs.beam.packagesWith interpreters.erlang;
      };
    };
  };
}

Prior to the generalization, I just did this:

{
  nixpkgs.config.packageOverrides = pkgs: rec {
    erlang = pkgs.erlangR19;
  };
}

Maybe you can show me a better a way and maybe we can add that to the docs.

@yurrriq That's a good piece of feedback! I am not sure how this can be done better.

I see two problems:

• if you override beam.interpreters.erlang it should switch beam.packages.erlang to the same version automagically (this is probably fixable by adding a fixpoint inside beam itself);
• the fact that you need to manually go first into beam, then into interpreters to do the override of beam.interpreters.erlang is a bit ugly - I suspect some sort of override function can be added inside beam to make this easier.

I will take a look sometime this week.

I think would be useful to include erlang in the beamPackages attrset, then people can refer to that to get the correct version.

@yurrriq Note that overriding the interpreter like that has undesirable side effects, it causes top-level packages like couchdb to potentially break.

@LnL7 I would be thankful if you provide guidance how to best structure ability to do the overrides on the levels where it is missing, as @yurrriq pointed out.

Is there anything else that needs to be done before this can be merged?

@ankhers, I think we should at least add some documentation re: clean(er) overrides, including the caveat @LnL7 pointed out, and maybe clean that up in general, perhaps as @gleber mentioned.

Re @LnL7's point: I agree. Really what I'm after is for my system-wide erl to be R19 and for LFE to be built with R19 too. I think I could instead include beam.interpreters.erlangR19 in my systemPackages and override (or build a separate) LFE to use R19. If nothing else, I think some related examples in the docs would be highly beneficial.

@yurrriq I thought this would prevent the need for override? I thought that this change allowed you to install beam.packages.erlangR19.lfe to have it build on R19.

Right, I think so. It'd be good to add a couple similar examples to the docs. /me checks the existing docs

I've got some pedantic edits (spelling, grammar, continuity, etc) for the docs and can add some examples like I've mentioned. Otherwise I think this is good to go.

Thinking on it more, I don't think we need to support such dramatic global overrides as I've got on my system now (see above).

@gleber, I'll open a PR to your branch, unless you have another suggestion.

Feel free to merge the PR as is - I think it already provides good value. I will continue refining it in various ways.

@yurrriq, sounds good. I will incorporate it into my work (regardless of the timing which PR gets merges/proposed first).

@gleber: gleber#1

We've merged in spelling/phrasing tweaks, including @ankhers's suggestion of normalizing BEAM throughout, but I didn't add any examples as discussed. I should be able to get to that later today.