It is intended as a replacement for the existing search.nixos.org/flakes. We are fully committed to making Flakestry an official Nix project, thus replacing the existing registry.
If you want to help out, it would be interesting to see someone play with flake output JSON and display the outputs alongside the README.
A note on flakehub.com/mynixos.com: these heroic efforts demonstrated that people liked the idea of having a central flake registry. We wanted to avoid the issues that are caused when a company controls the registry (eg: NPM) so we built a flake registry that is part of the Nix community in similar spirit like PyPi, Hackage, etc.
This is so cool to see. I’m glad to see an open source implementation of flakehub, and am excited to see validation of the core value proposition of semantic versioning being relevant and important to the nix ecosystem. Well done, congratulations. Congrats on the launch!
I would be interested in contributing code to make regular backups. Ideally those backups could be also made public because than we could start archiving all flakes.
I think multiple competing registries, including people hosting their own, is even better than a single community registry, so this is good.
The notion of centralization that registries imply is what makes them iffy — centralized human readable names is in opposition to the general nix philosophy of trustlessness and things being freely combinable (no collisions, no conflicts, etc.). Having multiple registries re-decentralizes things — unhappy someone is squatting a name? Just create your own registry! This is unambigiously good.
Also, I hope eventually at least one things don’t care about flakes at all. As we’ve discussed on the Nix Team, registries are a fetching concept, and fetching is conceptually prior to flakes (see WIP: Generalize the fetcher registry to not be flake specific by Ericson2314 · Pull Request #9085 · NixOS/nix · GitHub). Of course, I imagine it is good for registries to enforce additional structure — otherwise they are just a glorified bad version control — but there are many ways one might want to do that.
Looks good! Also nice to hear it will replace search.nixos.org/flakes. I was a bit worried seeing the title that there would be 3 different similar services for flake discovery
Edit: thinking about this a bit more, since semantic versioning was mentioned. So it might be to refer to some stable x.x.y version range. However, we already can refer to branches which seems more powerful than versions? An vx.x branch might already be just as useful? But a beta/staging branch is also possible (something that can be inconvient using version numbers). Am I overlooking something?
I think it’s just that not all projects (especially small ones) necessarily use a branch structure that exactly mimics their semantic versioning / release structure, or use a consistent structure between or even within each other.
That is certainly the case with rust crates, and likely many similar things in other languages, where the semantic versioning is resolved from metadata within the package content.
