nixpkgs as a mono repo might’ve been a mistake, honestly. shithub wasn’t made for monorepos. It doesn’t have a permissions system for it.
So many PRs get a bunch of inane comments that have nothing to do with the functionality to please somebody’s ego, the CODEOWNERS file is nearly worthless as “package maintainers” don’t even have the last say on their own packages, docs are nearly the last of the priorities making it difficult for pretty much anybody but the christened cream of the crop to make changes. It almost seems like the entire thing was made for “job security” - only a few people really understand what’s going on and thus make the decisions. That of course introduces a bottle-neck.
Even if more people wanted to contribute, they wouldn’t be aren’t able to. I think the decision makers like it that way.
The entire thing consists of 6 million objects and is 5GiB. I feel like at this point they should just split the common code into a repo and have the packages in submodule buckets grouped by name like some sort of hashmap multirepo (only half kidding).
I do wonder how nix could solve the nixpkgs problem. In order to build it actually requires the recipes to calculate the hash with which it builds the store path.
Fixed output hashes could be part of the solution. A map of package and version to hash and outPath maybe? But for building from scratch e.g new packages, where would the recipes be stored? I think it would have to be in git, but where would that be stored? A monorepo again? Then we’d be back at nixpkgs.
honestly, having just tested it, i think the solution might be as simple as --depth=1. for me, the clone time of some repos went from several minutes down to instant. even without that, there’s no reason in my mind why the filesystem can’t be used as a database, just with its own non-git tooling.
i was gonna be shocked that nix doesn’t store its own output hashes but then i realized guix doesn’t either. it seems really odd to me for a reproducible build package manager not to do that. i wonder what caused that decision.
nixpkgs as a mono repo might’ve been a mistake, honestly. shithub wasn’t made for monorepos. It doesn’t have a permissions system for it.
So many PRs get a bunch of inane comments that have nothing to do with the functionality to please somebody’s ego, the CODEOWNERS file is nearly worthless as “package maintainers” don’t even have the last say on their own packages, docs are nearly the last of the priorities making it difficult for pretty much anybody but the christened cream of the crop to make changes. It almost seems like the entire thing was made for “job security” - only a few people really understand what’s going on and thus make the decisions. That of course introduces a bottle-neck.
Even if more people wanted to contribute, they
wouldn’t bearen’t able to. I think the decision makers like it that way.The entire thing consists of 6 million objects and is 5GiB. I feel like at this point they should just split the common code into a repo and have the packages in submodule buckets grouped by name like some sort of hashmap multirepo (only half kidding).
this article mentions nix by name
I do wonder how nix could solve the nixpkgs problem. In order to build it actually requires the recipes to calculate the hash with which it builds the store path.
Fixed output hashes could be part of the solution. A map of package and version to hash and outPath maybe? But for building from scratch e.g new packages, where would the recipes be stored? I think it would have to be in git, but where would that be stored? A monorepo again? Then we’d be back at nixpkgs.
honestly, having just tested it, i think the solution might be as simple as
--depth=1. for me, the clone time of some repos went from several minutes down to instant. even without that, there’s no reason in my mind why the filesystem can’t be used as a database, just with its own non-git tooling.i was gonna be shocked that nix doesn’t store its own output hashes but then i realized guix doesn’t either. it seems really odd to me for a reproducible build package manager not to do that. i wonder what caused that decision.