FlakeHub provides the Nix ecosystem with a variety of new capabilities:
The ability to explore the Nix flake landscape.
Semantic versioning for flakes, including version modifiers like ~ (flexible patch) and = (exact match).
Automated flake publishing with GitHub Actions.
We believe FlakeHub will be a transformative force in the Nix ecosystem and provide a crucial inflection point for flake adoption inside and outside the Nix community.
We are all in on Nix flakes because we firmly believe that they are the future of Nix. FlakeHub.com joins our growing collection of Nix tools, and we look forward to you trying it out!
You can find out all the details in our Introducing FlakeHub blog post, and we invite you to join us on Discord where you can share your questions and feedback.
I am very disappointed. Instead of focusing on actually fixing problems with Flakes and trying to stabilize them, DetSys goes full in on experimental Flakes, advertising them as the future, ignoring all problems with them and building products on top of them. Meanwhile everybody trying to help out official efforts, the Nix team, Nixpkgs maintainers, the documentation team and more are suffering because Flakes isn’t stable. It seems like DetSys has no interest in alleviating the pressure and bridging the gap that Flakes has created in the community.
And more concretely, it’s a well-known problem that Flakes suffer from an explosion of dependencies with little reuse and interoperability. The design of how dependencies are locked just isn’t right. But oh surprise, that’s exactly what FlakeHub seems to help with by adding an ad-hoc third-party versioning scheme on top of Flakes. And all that centralised (wasn’t the whole point of Flakes to not be centralised?), proprietary and with seemingly no intention of upstreaming it in any way.
FlakeHub not only indexes flakes, but provides a mechanism for fetching compatible versions based on Semantic versioning — and, unlike pinning tags in your flake.nix inputs, keeping them up to date.
This means that you can specify that you want your input to be compatible with whatever is the latest release at the time that you add it, and get bugfixes with every nix flake update, without manually having to keep track of the releases made upstream, nor follow a development branch which may introduce breaking changes at any time.
Right now we only support GitHub because of the authentication model it offers with JWTs. We’ll be expanding this to support publishing in other forges, and locally too.
There’s been some RFC work in that direction, and we’d like to see that happen, too. In the meantime, the proof of concept of FlakeHub took about a weekend to put together. The core concepts to implement what we have here is built in to Nix.
Graham has mentioned the planned future support for other forges. That aside, it is possible, as a workaround, to create a GitHub repository which takes care of this. Any repository owned by you on GitHub can publish flakes under any name on the fgaz namespace on FlakeHub, so you could have a single repository that fetches your projects from other forges and publishes them to FlakeHub from there.
Unfortunately that’s forbidden by the GitHub terms of service:
Actions should not be used for:
[…]
if using GitHub-hosted runners, any other activity unrelated to the production, testing, deployment, or publication of the software project associated with the repository where GitHub Actions are used.
edit: and it requires a GitHub account. I still have one so I can contribute to other people’s projects, but many people don’t
I’m sorry some folks aren’t excited about FlakeHub, but that is okay. We’ve made it because it solves real problems we’ve experienced, and I think it is going to make a big difference in the community. We’re all contributing to the project in the ways we want to, and this is an example of that.
We see flakes as the future of Nix, and we’re unabashedly working to make that true. One way we’re doing that is using flakes extensively every day and exposing ourselves to the bugs, papercuts, and pain points. We often deeply research and resolve these problems upstream, without fanfare or posting on Discourse.
I think we have the common goal of growing and improving Nix, and we’re glad to be doing it together. We would love to see a continuation of RFC-144 accepted into Nix upstream. The version resolving feature of FlakeHub is a bandaid that works until the upstream project has a comparable feature. In my opinion, it is a good thing to do experiments like this without committing the entire project to it.
If you have been working to resolve things upstream, then now’s a good time to mention it. Because as far as I know, all of the major problem with Flakes are still as unaddressed as they were years ago and I have not seen any contributions by DetSys in that direction, but maybe I just missed it?
Yet the RFC was closed due to lack of interest. If you knew about it, why not help out with such efforts? Similarly, I also don’t recall anybody from DetSys participating in RFC 136 (not that it’s a big milestone, but it’s going in the right direction).
Ok so here’s another question, couldn’t this be added to nixos-search, as it’s already an official and very popular tool? If DetSys truly feels FlakeHub is solving a real problemsthe Nix ecosystem suffers from, why not add it to Nix itself, even if for now it just means adding it tom the officialsearch.nixos.org website?
It feels like it’s a common occurrence for DetSys to make an announcement on Discourse about a project they’ve been working on in private rather than helping with already existing community or official efforts, just like what happened with zero-to-nix.com and its feedback from the community. The lack of transparency isn’t a good look.
If you feel like the already existing efforts/projects aren’t being done right or are going in the wrong direction, can’t you communicate that publicly instead of starting (in private) a brand new third-party project? (Especially when it comes to something you claim it “solves real problems” and that it will make “a big difference in the community”)
We often deeply research and resolve these problems upstream,
What went wrong in FlakeHub’s case? Why was this not resolved in upstream? (maybe search.nixos.org?) It seems search.nixos.org already supports some sort of Flake-related functionality.
I would be very happy if Flakes just became a Determinate Systems project that was not part of the Nix repo. I don’t like maintaining Flakes, and if they were taken over like that then they would not longer be partially my problem (as a Nix Team member). Determinate Systems can them evolve them as they see fit. Win—Win!
I think that the way in which this was developed and in which it is being presented makes it very clear that you are not doing this for the good of the community, since in that case you could have involved the community, developed this in the open as part of the nix FOSS project, and offered to host it on community infrastructure.
But you didn’t do any of that, and I don’t think we need a proprietary walled garden as part of the nix ecosystem.
.
