> Not sure I'd use the term "hacks", but there are several ways you'd be able to refer to a v1.1 package, depending on what you're trying to do.
Yeah, this is the part I find a bit silly. There should be one way to do this. What I want to do is pin an Erlang version (down to semver patch) and then pin an Elixir version that’s compatible with it (also to semver patch). This is trivial to do with my existing tools (asdf/rtx and Dockerfiles), but it doesn’t have first-class support in Nix. I have to build that capability myself! I was absolutely floored by this after hearing so much about how seriously Nix takes reproducibility.
Similarly, the default Elixir and Erlang packages don’t even have a version, you have to use one of the special elixir_1_14 packages to get a specific minor version. The default Elixir just gets the latest release at the time nixpkgs was released. I can pin nixpkgs trivially but it’s not intuitive to pin individual packages across nixpkgs releases. Clearly this is just how Nix works, but because it’s not how any other dependency managers work, it’s a lot harder to integrate piecemeal.
edit: to Jetpack’s credit, this is one of the things I really like about Devbox. It makes pinning minor versions easy!
I think DevBox make use of an index where it shows the nixpkgs version for different versions of different software. https://www.nixhub.io/packages/erlang
Note that this approach isn't without its downsides (compared to overriding the version in nixpkgs, or using a separate nix package). -- Mainly, since it uses an older nixpkgs version, the dependencies will also be that old version. (They won't have any security fixes which have been released since then; and it'll take up more disk space to install).
> Similarly, the default Elixir and Erlang packages don’t even have a version, you have to use one of the special elixir_1_14 packages to get a specific minor version.
Supporting multiple versions be more helpful at the cost of more effort to maintain. It's a reasonable tradeoff that nixpkgs provides the latest, and if you want anything other than what nixpkgs provides, you write some nix for that.
> I think DevBox make use of an index where it shows the nixpkgs version for different versions of different software
Correct.
> It's a reasonable tradeoff that nixpkgs provides the latest, and if you want anything other than what nixpkgs provides, you write some nix for that.
Reasonable for you, maybe. For me, I have dozens of Erlang projects on various versions that I don’t want to break to start using Nix, and Nix is significantly more effort to get a reproducible configuration than my current setup. Why bother? In what universe is it reasonable to make package consumers write software to consume different versions of a package? Tools are supposed to make our lives easier, not harder.
> In what universe is it reasonable to make package consumers write software...
Docker is also a tool where the UX is nicer if you write code (e.g. a Dockerfile) rather than using cli only (e.g. `docker commit`).
I don't think there's anyone who would prefer to use `docker commit` instead of using a Dockerfile.
With Nix, it's similar: only using Nix through the CLI, and not writing Nix code, is going to limit how useful Nix is.
In any case, you don't need to write Nix code to use a package from an older revision of nixpkgs. -- With different options, there are different trade-offs.
> Nix is significantly more effort to get a reproducible configuration than my current setup. Why bother? ... Tools are supposed to make our lives easier, not harder.
Yeah, Nix is much more difficult to use than other tools.
Nix's UX is one where you pay a big cost upfront in order to save on effort later.
e.g. that's comparable in Infra-as-Code, where writing Terraform is going to be slower than just managing stuff through a graphical console.
Yeah, this is the part I find a bit silly. There should be one way to do this. What I want to do is pin an Erlang version (down to semver patch) and then pin an Elixir version that’s compatible with it (also to semver patch). This is trivial to do with my existing tools (asdf/rtx and Dockerfiles), but it doesn’t have first-class support in Nix. I have to build that capability myself! I was absolutely floored by this after hearing so much about how seriously Nix takes reproducibility.
Similarly, the default Elixir and Erlang packages don’t even have a version, you have to use one of the special elixir_1_14 packages to get a specific minor version. The default Elixir just gets the latest release at the time nixpkgs was released. I can pin nixpkgs trivially but it’s not intuitive to pin individual packages across nixpkgs releases. Clearly this is just how Nix works, but because it’s not how any other dependency managers work, it’s a lot harder to integrate piecemeal.
edit: to Jetpack’s credit, this is one of the things I really like about Devbox. It makes pinning minor versions easy!
reply