Glad someone found them useful :)
127 karma · joined April 9, 2021
If you follow one for nixpkgs, it means that the infrastructure has at least attempted all possible builds. If you're starting to build something, it's likely broken. However, that's usually not the case. https://hydra.nixos.org/jobset/nixos/release-21.05
Otherwise, I would recommend looking at home-manager, it's essentially NixOS but for any linux distro, or even darwin with nix-darwin. https://github.com/nix-community/home-manager
Not to mention that nix can be used (with varying levels of success) on windows, intel macs, m1 macs, redoxOS, and others.
In general, it's write once, use anywhere.
This will create a python which has pync and other packages in the sitePackages already.
The last mile was done by removing the use of ruby (which uses some random tmp directories) from the final image. Asciidoctor (ruby) was replaced with asciidoc (python).
https://github.com/NixOS/nixpkgs/pull/126319
In response to "not having the latest": Generally we (nixpkgs) lag behind a bit, as managing ~60-100k packages takes some time. But as long as the process to build a package hasn't changed, we will have a bot which automatically attempts to update packages based on metadata from pypi, github, and repology.
NixOS is a linux distribution with a focus on reproducibility. It's built upon the Nix package manager, making system configuration declarative, reproducible, and atomic.
Learn more at: https://nixos.org/
But for most mature build systems we largely just use the toolchain as-is. CMake, pkg-config, autotools, and other toolchains or technologies generally allow enough flexibility to enable non-FHS builds to be done in a consistent and easy manner. Actually, creating nix packages for upstreams which have good release management discipline is trivial once you're familiar with nix.
What makes nix special is that you when you go to build the package, you reference the dependencies through their canonical name, but nix translates these dependencies to a unique paths which are hashed to capture all inputs (including configuration flags) used to create the dependency. So you can use multiple conflicting versions of a dependency in a package's dependency tree without issue. Dependencies can be shared if a dependency matches exactly, but can differ if needed. And that's something that FHS distros cannot do.
Actually, since nix never makes any assumptions about what's installed on the system, you're free to use it on any distro. And it's hermetic, so the host system wouldn't be changed outside of the `/nix` directory. You can even use is it even on macOS, although it's not as well supported, but should work fine for common packages.
> A middle ground could be distros can keep control over the version that's being statically linked at build time.
Nixpkgs already does this, even if the dependency is dynamically linked. So there's no additional overhead with switching it out to the static variants; other than upstreams may not support that scenario as well as "traditional" dynamic linking.
This can be address by adding the version to the dependencies store path. This has been done for rust builds, not sure about go.
Honestly, if people just used nix for `shell.nix` in projects, it's still major value added