Yes, they do have an agenda, because how else you explain patches like this:

https://github.com/NixOS/nixpkgs/blob/1137200d6b7fcf8fc401b5...

Note that they didn't fork the project under some different name, they shipped it like this under the original name.

Of course they have an agenda. Nix is one of the most opinionated Linux distros in existence. They have an absolute insistence on reproducible builds.

What I said was that they didn't have a secret agenda. They are completely up front about reproducibility. Code that violates this principle needs to be fixed (or disabled, as in this Rebar example).

If that doesn't meet your needs, then just move on. Nix isn't a distro that will please everyone.

rebar3 itself supports reproducible builds via lock files. Applying patches like this instead of embracing the right way that the upstream designed for this exact purpose is just ignorance.

I would be totally cool with any incompatible patches that distro makes for its needs, as long as the binary is renamed. But they shipped a broken binary and called it rebar3. Not "rebar3-nix", but "rebar3". People try using this binary for development and it doesn't work, they go to the upstream and the upstream spends time investigating someone else's hacks.

That's a fair point.

Dude, Debian does exactly this same exact thing to get reproducible builds. They generally submit things upstream, so I'm not aware of Nix attempts do the same, but I can also imagine their patches for reproducible builds might not make sense outside of Nix. This particular patch is done differently than how Debian attempts to do it (they try to make no changes to the code if possible), but this patch doesn't seem like a bad approach either (makes it obvious at least).

rebar3 itself supports reproducible builds, so applying patches like that and breaking it for anyone who uses it for local development is a problem.