Wow, i wasn't interested at first because i'm already using flakes and i didn't think this had much value to me - i don't mind adding a flakes repo directly, for example. Then someone linked the discussion on Discourse[1] which has..:
> 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.
Which is stupidly sexy to me. Semver-like is something i've been wanting so badly from Flakes/Nix. This has my attention now.
Something I've wanted is more customizable upgrade logic for selecting versions, especially upgrades for end-user packages. e.g. latest tagged release (without having to update the package/flake), latest tagged release but wait a week/month (like phased releases but end-user configurable), HEAD but no more than once a week (so you aren't compiling packages every day, c.f. emacs), whatever the latest version is provided it is in cachix, etc
I'm so glad you think so! We sure agree :). We're hoping this mechanism helps get some predictability, like that all the platforms that are listed fully evaluate as expected.
Are you able to elaborate on some of the shade being thrown in that linked thread? There appears to be some politics around this, or determinate systems, or something.
Not really, i don't follow it closely. I believe some others in this thread dive into it a bit.
My (mostly assumed!) takeaway is that Flakes isn't perfect, and many existing users don't like that a very important part of Nix is being rushed. Conversely, many Flakes users think almost the exact opposite -- that Flakes has been taking too long and Nix is incomplete without it (i'm more in this camp).
All around though i don't have the energy to partake in this holy war, so i mostly ignore it. I'm sure i am wrong on some important details, so please don't take what i say as more than it's worth.
Hey folks, Graham -- CEO of DetSys here. So glad to be able to share FlakeHub, our most ambitious project yet.
FlakeHub brings a crates.io-like experience to Nix and flakes, with semver releases and publish-time checks to make sure the flake is easily distributable.
Check it out, let us know what you think! I'll be here answering questions all day.
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.
As flawed as flakes are, they are significantly better than channels and all the hacks that surround them. Flakes are how I manage my system today and I honestly believe that there is no harm in building tooling around them - we all know that things are subject to change. This is now in my configs: https://codeberg.org/jcdickinson/nix/src/branch/main/flake.n...
Something I've noticed: `nixos/*` and `home-manager/*` are incompatible (home-manager expects 23.11 while nixos is 23.05).
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 64 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.
This all just doesn’t sit right with me :frowning:
I don't want to discredit what this person is saying at all but does anybody else read things like this in regards to open source software and instantly think "sheesh, that person could benefit from going outside and touching some grass every once in a while?"
Infinisil has over 600 commits in the Nixpkgs repo alone, and is also active in other codebases in the ecosystem.
This comment on Discourse has a lot of likes in part because people in the community recognize his username from his contributions even if they haven't worked with him.
He's not some random passerby throwing out an opinion about a project he has no stake in. He's a longtime, highly active contributor in the Nix ecosystem who cares about projects he's involved in and other efforts related to them.
You don't have to agree with his take but this is disrespectful and lame.
Perhaps a bit off topic, but I've been playing around with NixOS lately, and I don't understand what the advantages of using flakes are, or really what problem they solve. Granted, my interest in Nix is simply because I think it's cool to have the OS be configurable from a file, and I'm personally less interested in some of the reproducibility features. I've tried reading up[0] on some of the advantages of using them, but my eyes start to glaze over pretty quickly.
In a traditional nixos install you have two moving parts -- configuration.nix(and whatever modules it imports) and channels. Channels are updated independently which makes it harder to reason about the system at a specific point in time.
Flakes unify the two in a common interface. You have the "channels"(called "inputs" in flakes) pinned and the "configuration.nix" (now one of the outputs) pinned together.
That being said, you don't need to switch your system to a flake-managed one right away. If you enable the flags from that article, you can run things from flakes using "nix run". This will transparently pull the flake to your machine and evaluate the output you wanted.
> That being said, you don't need to switch your system to a flake-managed one right away. If you enable the flags from that article, you can run things from flakes using "nix run". This will transparently pull the flake to your machine and evaluate the output you wanted.
That's where I am in my slow transition to flakes. Still basing my system on a monolithic configuration.nix, but with flakes enabled so I can experiment with them or use them in dev projects as opportunities arise.
One day I'll get around to fully transitioning over to flakes, but it's nice that there's this intermediate step and no rush.
A flake.nix file is somewhat comparable to a package.json file in a NodeJS project.
Similar to how package-lock.json records the exact version of packages used to build a nodejs project, a flake lockfile will record the exact version of nixpkgs (and other nix dependencies) the flake uses.
The other thing a flake.nix file provides is a consistent entrypoint to a codebase. Previously, by convention, projects might have a `default.nix`, but one default.nix might be a different form than another default.nix.
The consistent entrypoint allows for a really nice UX for both referring to other nix codebases, as well as a Docker-like UX for running code which has a flake.nix.
Flakes advantages are sometimes more immediately noticeable when not running NixOS, since the unstructured nix expression system used by default in that scenario is not helpful Vs a flake with its structure allowing a standardized way to express many things.
With a project specific flake you can specify not only how to build your package, and how to run it, (includable ability to specify "apps" for each executable of a multi-executable package), but also specify a development environment for developing on the package with the exact compiler versions and everything this package wants. (The convenience of a development container, but without limitations of developing in a container.)
This can obviously be extended further to defining nixos modules, which could be useful if your package is a service that people might want to pull in to nixos.
--
Some flake features like defining nixosConfigurations or homeConfigurations are not really sensible for a package-specific flake but can be useful if defining a flake for say your lab of NixOS systems. That is one advantage over classic nixos configurations. You can have a flake that defines the configurations of multiple systems.
Indeed, even if you don't want one master flake for all your machines, you may still want a separate flake for your a home-manager configuration that you can pull in when defining a specific system in a system-specific flake.
Perhaps it is just me. But after so many attempts of trying to getting started with Nix, it is still not clear to me how to *author* Nix packages. My mental model about Nix is that it resembles make, but for the whole dependency graph. I kind of hoped that the Nix language is more sane. I think there is a project of similar goals but the script is in Python? I remember finding it once, but couldn't recall its name.
My understanding is that Nix was initially invented to solved the "producing builds with a fully specified dependencies graph" problem; people then figured out that it can dub as a package manager to support a better developer experience.
Docker, on the other hand, was introduced to solve the deployment problem --- it provides light-weight isolation so that you get boggled in resolving dependency conflicts. Of course, people later also use it drive development environments, which I find quite sensible.
> My mental model about Nix is that it resembles make, but for the whole dependency graph.
I just started learning about nix a few days ago. I'm still a little bit confused and flakes are an abstraction, i didn't tackle so far.
My mental model is, that it resembles sth. like virtual environments for python or nvm for node.js installations. At least that's what i want to use it for.
This is awesome! We used a similar SemVer interface for installing standard nix packages on Nixhub (www.nixhub.io), and a lot of users told us it was a killer feature. Having a nice search interface should help a lot with Flake discoverability, which is currently a big challenge.
Yeah, thanks. We only support GitHub Actions because of the authentication model it offer with JWTs. We're planning on expanding to support other forges, and eventually local publishing, too.
In the meantime, you could use a GitHub action to clone your repository from another forge and publish it, if you wanted to.
> We're planning on expanding to support other forges,
Just want to put in a request for SourceHut support in case it's not already on your list. Sometimes it gets overlooked in favor of the big corporate forges.
I see, so to confirm, I could have the workflow in a seperate repo than the repo I'm publishing? That would solve my concerns.
I see in your docs that there is a repository config option, so that could work. If directory works with a submodule or repo pulled in previous job, that could also be an option. I'll give it a try later.
Delighted to finally see FlakeHub out in the wild. Keen to answer questions, but if you'd like a direct community with the DetSys team we invite you to join us on Discord: https://discord.gg/invite/a4EcQQ8STr
Readit News
> 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.
Which is stupidly sexy to me. Semver-like is something i've been wanting so badly from Flakes/Nix. This has my attention now.
[1]: https://discourse.nixos.org/t/introducing-flakehub/32044/6
My (mostly assumed!) takeaway is that Flakes isn't perfect, and many existing users don't like that a very important part of Nix is being rushed. Conversely, many Flakes users think almost the exact opposite -- that Flakes has been taking too long and Nix is incomplete without it (i'm more in this camp).
All around though i don't have the energy to partake in this holy war, so i mostly ignore it. I'm sure i am wrong on some important details, so please don't take what i say as more than it's worth.
FlakeHub brings a crates.io-like experience to Nix and flakes, with semver releases and publish-time checks to make sure the flake is easily distributable.
Check it out, let us know what you think! I'll be here answering questions all day.
You can search on the web UI, though: https://flakehub.com/search
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.
Something I've noticed: `nixos/*` and `home-manager/*` are incompatible (home-manager expects 23.11 while nixos is 23.05).
Oh, and it has 50 likes, lol
This comment on Discourse has a lot of likes in part because people in the community recognize his username from his contributions even if they haven't worked with him.
He's not some random passerby throwing out an opinion about a project he has no stake in. He's a longtime, highly active contributor in the Nix ecosystem who cares about projects he's involved in and other efforts related to them.
You don't have to agree with his take but this is disrespectful and lame.
[0] https://nixos.wiki/wiki/Flakes
Flakes unify the two in a common interface. You have the "channels"(called "inputs" in flakes) pinned and the "configuration.nix" (now one of the outputs) pinned together.
That being said, you don't need to switch your system to a flake-managed one right away. If you enable the flags from that article, you can run things from flakes using "nix run". This will transparently pull the flake to your machine and evaluate the output you wanted.
That's where I am in my slow transition to flakes. Still basing my system on a monolithic configuration.nix, but with flakes enabled so I can experiment with them or use them in dev projects as opportunities arise.
One day I'll get around to fully transitioning over to flakes, but it's nice that there's this intermediate step and no rush.
Similar to how package-lock.json records the exact version of packages used to build a nodejs project, a flake lockfile will record the exact version of nixpkgs (and other nix dependencies) the flake uses.
The other thing a flake.nix file provides is a consistent entrypoint to a codebase. Previously, by convention, projects might have a `default.nix`, but one default.nix might be a different form than another default.nix.
The consistent entrypoint allows for a really nice UX for both referring to other nix codebases, as well as a Docker-like UX for running code which has a flake.nix.
With a project specific flake you can specify not only how to build your package, and how to run it, (includable ability to specify "apps" for each executable of a multi-executable package), but also specify a development environment for developing on the package with the exact compiler versions and everything this package wants. (The convenience of a development container, but without limitations of developing in a container.)
This can obviously be extended further to defining nixos modules, which could be useful if your package is a service that people might want to pull in to nixos.
--
Some flake features like defining nixosConfigurations or homeConfigurations are not really sensible for a package-specific flake but can be useful if defining a flake for say your lab of NixOS systems. That is one advantage over classic nixos configurations. You can have a flake that defines the configurations of multiple systems.
Indeed, even if you don't want one master flake for all your machines, you may still want a separate flake for your a home-manager configuration that you can pull in when defining a specific system in a system-specific flake.
Perhaps "Docker, without containers" would be a closer way to convey what Nix does.
With Docker, images get built in a fresh/sandbox environment, and the resulting image is easy to distribute to other systems running Docker.
> I kind of hoped that the Nix language is more sane. I think there is a project of similar goals but the script is in Python?
A project quite related to "Nix (but not using a bespoke DSL)" is Guix, which uses Scheme.
Perhaps you're thinking of Bazel? Which uses a Python-like language, and (AFAIU) is much closer to "like make, but for the whole dependency graph".
Docker, on the other hand, was introduced to solve the deployment problem --- it provides light-weight isolation so that you get boggled in resolving dependency conflicts. Of course, people later also use it drive development environments, which I find quite sensible.
I just started learning about nix a few days ago. I'm still a little bit confused and flakes are an abstraction, i didn't tackle so far.
My mental model is, that it resembles sth. like virtual environments for python or nvm for node.js installations. At least that's what i want to use it for.
https://dhall-lang.org/
https://news.ycombinator.com/item?id=32102203
https://news.ycombinator.com/item?id=31658638
Great work from the Determinate Systems team!
I would be interested in it if it didn't require github and github-specific configuations like github action workflows.
In the meantime, you could use a GitHub action to clone your repository from another forge and publish it, if you wanted to.
Just want to put in a request for SourceHut support in case it's not already on your list. Sometimes it gets overlooked in favor of the big corporate forges.
https://sourcehut.org/
I see in your docs that there is a repository config option, so that could work. If directory works with a submodule or repo pulled in previous job, that could also be an option. I'll give it a try later.