The main idea behind this project is to provide a quick and simple interface for publishing Nix flakes.
Flakes have become relatively mature and address the central repository issue. However, the Nixpkgs repository on GitHub still has more that 5k open issues and a comparable number of pull requests, and continues to receive many commits every day. Getting a pull request for a new tool merged into Nixpkgs can be difficult - the Nixpkgs README explicitly discourages people from submitting their “pet” projects.
The Nixpkgs repository is huge. It contains more than 120k packages, but the majority of them are not native to Nix. For example, about 10% are Haskell packages imported. Therefore, this large number cannot be used as a reliable measure of how well the publishing process is developed in Nix. For instance, the PyPy repository alone currently contains almost 900k packages.
It is also important to note Python is the most popular general-purpose programming language, and its publishing process was designed by programmers for programmers. Yet there is no pull-request step in the workflow. The interface is essentially “upload and forget”, which has a significant positive impact on the conversion funnel of Python packages.
Flakes are easy to install, but the publishing workflow is not yet polished enough. The current approach to distributing flakes appears to have inherited many characteristics of the Nixpkgs workflow.
For Nixpkgs, this was the natural way of development, because all derivations form a large and coupled Nix expression split across many files within a single Git repository.
Nice project!
But I feel there are some gaps here:
Why is nixpkgs being big is a problem, github eats the hosting cost after all. Why do we care how much MS has to pay for it?
How flake solve the issues with nixpkgs being big? as far as I can tell, every flake I’ve seen uses nixpkgs. You’d need some way to bootsrap a nix ecosystem without nixpkgs. An indexing site doesn’t do this (although it may help with discoverability)
How flakes compose? As far as I can tell they don’t. An example of flake composition would be nice. Composition is the fundemental problem you need to solve to split up a big thing (nixpkgs) into smaller parts.
I’m asking these questions so you can explain your project better.
I keep a nixkpgs git repo on my PC and I noticed that GH just throttles download speed to 0 in case of pulling changes after long period. So I had to setup a “cron job” to pull changes every night. It is terrible for doing occasional contributions.
From a user perspective fetching a nixpkgs snapshot in form of a tar file takes lot of traffic and time. I have to worry about minimizing number of roots and keep in sync nixpkgs across my projects.
To mitigate loads of PRs - nix discourse has the endless thread for asking help with merging PRs.
Repo size is not only a problem by itself, but a sign that flakes are not working well.
It is like having a repo with /etc/hosts for the whole world instead of DNS.
Central repo at early stages helped nix to consolidate efforts, but it is an obstacle on the way to mainstream technology. Mandatory PR make nixkpkgs less inclusive than it could be.
Pet projects are grass root.
Flakes can reference other flakes. Nixpkgs is just a flake, but a very big one. So e.g. a flake of a Haskell program could reference just a flake with Haskell packages instead of the whole nixpkgs.
Flakes are pure functions with default arguments.
Flake can override an argument of a flake it depends on.
The composition problem for flakes is there not much reusable flakes and there is no convenient mechanism for flake discovery and the wheel has turned full circle.
I wasn’t aware of that project, but I anticipated I wouldn’t be the first to explore this idea. It’s too obvious and straightforward to have remained untouched for the years that flakes have existed. I was primarily motivated by the opportunity to experiment with the STM library, which plays a key role on the server side. At the moment, I’m working on an alternative frontend built with Miso.
Miso seems production-ready: the compressed JS bundle is smaller than Bulma’s minified (but uncompressed) CSS file. I remember choosing Bulma about 10 years ago precisely because it was a tiny and simple library.
The open-source aspect of such a project is not particularly important, since it mainly addresses discoverability, and local instances provide limited value.
One difference I noticed at first glance is that the system requires login. I skipped it, since it feels unnecessary in this context—flakes are hosted on GitHub anyway.
