How do I specify minor versions for Erlang and Elixir?

Help
1

Nixpkgs includes a couple of recent major versions of Erlang/OTP and Elixir, but I would like to be able to specify precise versions of these languages.

For example, to get Erlang 27 and Elixir 1.17 (additionally having this Elixir compiled with this Erlang version) I can do: beam.packages.erlang_27.elixir_1_17

But what if I want to be precise: Erlang 27.2 and Elixir 1.17.0? How would I do this?

This also applies to erlang_nox. This package follows whatever the latest erlang is, but what if I want to specify this version?

I’ve seen the example of the overlay in the beam section of the nixpkgs manual, but it doesn’t fully cover what I need.

Thanks :slight_smile:

2

https://nixos.wiki/wiki/FAQ/Pinning_Nixpkgs

3

How do I use this to only pin Erlang and Elixir? I don’t want to use old versions of every single package just because I want to use a year old erlang_nox version, as an example

4

It is a little hard to see the link actually, apologies.
Go here: Nix Package Versions
Search your pkg.
Found it, say we want to install version 1.17.2, click on that section.
Nix Package Versions

Install elixir

Package elixir
Version 1.17.2
Channel nixpkgs-unstable
Revision 05bbf675397d5366259409139039af8077d695ce

Install elixir with nix-env.

nix-env -iA elixir_1_17 -f https://github.com/NixOS/nixpkgs/archive/05bbf675397d5366259409139039af8077d695ce.tar.gz

Use elixir_1_17 in a nix-shell.

nix-shell -p elixir_1_17 -I nixpkgs=https://github.com/NixOS/nixpkgs/archive/05bbf675397d5366259409139039af8077d695ce.tar.gz

Use elixir in a nix script via tarball

let
    pkgs = import (builtins.fetchTarball {
        url = "https://github.com/NixOS/nixpkgs/archive/05bbf675397d5366259409139039af8077d695ce.tar.gz";
    }) {};

    myPkg = pkgs.elixir_1_17;
in
...

Use elixir in a nix script via Git

let
     pkgs = import (builtins.fetchGit {
         # Descriptive name to make the store path easier to identify
         name = "my-old-revision";
         url = "https://github.com/NixOS/nixpkgs/";
         ref = "refs/heads/nixpkgs-unstable";
         rev = "05bbf675397d5366259409139039af8077d695ce";
     }) {};

     myPkg = pkgs.elixir_1_17;
in
...
1 Like
5

We usually do not do that when working with nix.

Though if you really want to, there has been a flake once that was able to read a .tool-versions and would produce a development environment with exactly that versions of erlang and elixir and compiling them together. The author abondoned and deprecated it though for personal reasons and I can’t find a link to it in my notes. It is also not compatible with recent nixpkgs, due to a rename in the erlang* attributes.

There is also @adamcstephens beampkgs, which should be kind of a replacement as far as I understand, though as there is neither a README nor a LICENSE, I never dug deeper into it.

1 Like
6

nix-beam-flakes! That is what I used, and its deprecation is too bad indeed.

I haven’t seen this one before. I’ll try it out, thanks!

Even in the context of personal projects and/or professional environments? I can understand the sentiment when packaging for nixpkgs itself, but I feel like at times there would be a need for “we tested it on this version, and it works.” Sometimes you want to delay upgrading and testing the language in combination with the project, but you don’t want to keep every package outdated by sticking with an older version of nixpkgs (e.g., some development dependencies like git)

(I feel like this last paragraph is a bit of a ramble but I hope that you get what I mean)

7

Why should I care for the patch versions of elixir and erlang, if I can simply say, everything is built on top of nixpkgs commit foobar?

Everything else just is a result of that.

I’m using erlang and elixir as coming from nixpkgs just fine at work. There have not been any problems because I have been slightly off by a patch version.

Poeple think pinning the runtime and compiler down this strict would help against the “works for me” syndrom, while forgetting that the remainder of the system is the bigger problem…

The differences between how loading and finding dynamic libraries on MacOS works differently than on Linux has been the biggest pain in the team when we introduced something that used a NIF (I have to admit I do not remember what it was exactly).

A tool-version with specific patch versions of elixir, erlang and even node, wouldn’t have helped with this…

1 Like
8

beampkgs probably isn’t fully usable. I spent some time hacking on it one day, but got hung up in some layout decisions. Lately I’ve been more focused on improving beam support in nixpkgs itself and hope to continue there. I’ll archive the project for clarity, but the lack of docs was on purpose given its state. :slight_smile:

Supporting more than one individual minor version at a time is not really feasible from a complexitymaintenance standpoint and to @NobbZ’s point isn’t really necessary. If you absolutely need to try an older minor release then you can see if it’s in the history of nixpkgs or do an override. Otherwise, you’re probably safe using the standard nixpkgs versions. Either way you want to pin.

2 Likes