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.

[–] into_highest_invite@lemmygrad.ml 1 points 23 hours ago (1 children)

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.

[–] onlinepersona@programming.dev 2 points 12 hours ago (1 children)

Isn't that part of the problem described in the article? A shallow clone? Github has trouble with exactly that.

Maybe it's time the community stepped in an provided alternative solutions to nixpkgs. We can talk about them here, but in the end somebody has to implement them.

[–] into_highest_invite@lemmygrad.ml 2 points 12 hours ago* (last edited 12 hours ago)

no shallow is --shallow. the difference is --depth refers to the history (as reported by, e.g. git log), whereas shallow will only check out the root of the repository and any paths explicitly specified. i guess the article is describing some sort of problem with users who convert their shallow repository to a regular full repo. i wouldn't know a lot about that.