| There isn't a whole lot of software that has turned their Git repository into a Flake yet (i.e. added a flake.nix) As long as the project developers are not going to use Nix themselves, there are going to be a lot of unmaintained, broken flakes. All dependencies are pinned, but the project itself may move on from what is specified in the flake. A bunch of my own projects were flakes [1], but they would regularly break, because the project would move on (e.g. requiring a newer version of libtorch), but I forgot to update flake.nix/lock. Of course, you can still run historical versions, but when the main path doesn't work, many users will just move on. So, including Nix flake files becomes more of a liability to a project than an asset. (Besides that, it probably fills your store with many, potentially vulnerable versions of glibc and whatnot due to use of many different nixpkgs revisions, a problem that the centralized nixpkgs package set doesn't have.) [1] I even implemented/contributed the cargoLock functionality, so that you can use buildRustPackage (rather than an external solution) without needing to specify the Cargo vendoring hash to make it easier to use buildRustPackage in your own repositories: https://nixos.org/manual/nixpkgs/stable/#importing-a-cargo.l... |