Show HN: FlakeHub – Discover and publish Nix flakes(flakehub.com)
flakehub.com
Show HN: FlakeHub – Discover and publish Nix flakes
https://flakehub.com/
110 comments
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.
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.
The problems here are not exactly flakes going too slow or too fast.
It is that the historical developer of nix, who was also behind flakes, moved to create a company called Determinate Systems. And this company keep pushing out products that are "ways to fix all kind of problems with nix and flakes".
Except they are done in secret then announced, while the rest of the community is trying to actually make the underlying stuff just work.
It is a bit like the guy built a half finished stuff, good enough for him, leave it in this state, then keep coming back with "solutions" that are not in nix themselves. And let everyone else clean his stuff.
Ofc the other way to look at it is that they are the only one having results and really fixing things. But I am on the side of all the other maintainers that keep having to clean up the mess.
It is that the historical developer of nix, who was also behind flakes, moved to create a company called Determinate Systems. And this company keep pushing out products that are "ways to fix all kind of problems with nix and flakes".
Except they are done in secret then announced, while the rest of the community is trying to actually make the underlying stuff just work.
It is a bit like the guy built a half finished stuff, good enough for him, leave it in this state, then keep coming back with "solutions" that are not in nix themselves. And let everyone else clean his stuff.
Ofc the other way to look at it is that they are the only one having results and really fixing things. But I am on the side of all the other maintainers that keep having to clean up the mess.
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.
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 couldn't find a command line interface for searching the flakes, did I miss it?
We don't have one yet, but watch for one in the coming weeks. The CLI we're putting together allows for searching and adding to your flake.
You can search on the web UI, though: https://flakehub.com/search
You can search on the web UI, though: https://flakehub.com/search
Isn't crates.io owned by The Rust Foundation?
"crates.io-like"
Would it make sense if crates.io was owned by a 3rd party? I don't think I would use it.
So shouldn't flakehub be owned by The NixOS Foundation instead of being a 3rd party and proprietary? It seems to be a critical feature for flakes.
So shouldn't flakehub be owned by The NixOS Foundation instead of being a 3rd party and proprietary? It seems to be a critical feature for flakes.
Oh I see what you mean, I misunderstood your comment.
Yeah I'm not sure what would be best in this regard. Flakes are on track to becoming a critical feature for Nix, though I'm not sure Flakehub will be a critical feature for Flakes. It seems there are some issues with standardization of pinning and versioning that need to be fixed in upstream, but the Flakehub folks seem committed to transitioning to those when fixed:
https://discourse.nixos.org/t/introducing-flakehub/32044/14
As long as those standards get worked out upstream and Flakehub and similar projects follow them, and they're technically interchangeable, then they may be ok. It's if there are a bunch of different proprietary solutions with different proprietary standards where it becomes problematic.
Yeah I'm not sure what would be best in this regard. Flakes are on track to becoming a critical feature for Nix, though I'm not sure Flakehub will be a critical feature for Flakes. It seems there are some issues with standardization of pinning and versioning that need to be fixed in upstream, but the Flakehub folks seem committed to transitioning to those when fixed:
https://discourse.nixos.org/t/introducing-flakehub/32044/14
As long as those standards get worked out upstream and Flakehub and similar projects follow them, and they're technically interchangeable, then they may be ok. It's if there are a bunch of different proprietary solutions with different proprietary standards where it becomes problematic.
Considering that flakes aren't a critical feature for Nix, it balances out.
It's not? I thought that the NixOS creator calling flakes "the future of Nix", implied that it kinda was.
A thing with a clunky UI that technically only restricts the capabilities of its parent tool is not the future. It's a tarpit for staying in the local optimum that most Nix use is in right now.
> It's a tarpit for staying in the local optimum that most Nix use is in right now.
I know that pre-flakes conventions for reusing Nix code are pretty open-ended, and naturally 'pure evaluation mode' means turning a bunch of things off. I can also see how if you are interested in integrations with stateful systems or maybe relaxing certain constraints or allowing/tracking some 'impurities', that might also seem like a step in the wrong direction.
Do you have any possibilities (or examples) in mind for how Nix might be used beyond the 'local optimum' of most current usage?
I know that pre-flakes conventions for reusing Nix code are pretty open-ended, and naturally 'pure evaluation mode' means turning a bunch of things off. I can also see how if you are interested in integrations with stateful systems or maybe relaxing certain constraints or allowing/tracking some 'impurities', that might also seem like a step in the wrong direction.
Do you have any possibilities (or examples) in mind for how Nix might be used beyond the 'local optimum' of most current usage?
I don't see Flakes as a decision that's impossible to work past more or less than traditional nix, given that you can use flakes from traditional nix (not as easily as overlays, I will give you that), and frankly refusing to take a real improvement for end users over a hypothetical better one that no one has managed to produce yet seems counter productive.
You're talking about a different thing. I'm not interested in Nix for end-users who maintain office suite installations and Steam on their desktop computers. By all means, if somebody wants to make a great UX improvement for that - go ahead, but it doesn't need to be in the core of Nix.
I don't think Nix really has a viable future without flakes
The reception on the nixos discourse is worth a look: https://discourse.nixos.org/t/introducing-flakehub/32044
I just posted a reply on Discourse (https://discourse.nixos.org/t/introducing-flakehub/32044/14?...) but for posterity:
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.
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).
Something I've noticed: `nixos/*` and `home-manager/*` are incompatible (home-manager expects 23.11 while nixos is 23.05).
Very cool!
You can get nixpkgs unstable like this:
You can get nixpkgs unstable like this:
nixpkgs-unstable.url = "https://flakehub.com/f/NixOS/nixpkgs/1.*.tar.gz";https://discourse.nixos.org/t/introducing-flakehub/32044/3
Oh, and it has 50 likes, lol
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:
Oh, and it has 50 likes, lol
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.
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.
> Infinisil has over 600 commits in the Nixpkgs repo alone, and is also active in other codebases in the ecosystem.
> people in the community recognize his username from his contributions
> 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.
Without doubling down on my viewpoint that you already think is lame and disrespectful, you don't think any of these achievements are probably mildly unhealthy/obsession level?
> people in the community recognize his username from his contributions
> 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.
Without doubling down on my viewpoint that you already think is lame and disrespectful, you don't think any of these achievements are probably mildly unhealthy/obsession level?
Open-source can be deeply rewarding and some people really pour themselves into it. I think assessing one's level of investment falls to each contributor themselves, and I wouldn't condescend to tell a stranger that they've made the wrong decision about that.
That said, a lot of people in the Nix community go above and beyond what could reasonably be asked of them by others, and it probably does put them at risk of problems including burnout. I'd be interested in research into emotional well-being and F/OSS involvement in general, because it could be really valuable in informing strategies for building F/OSS sustainably and even personal advice for staying balanced.
At the individual level, though, concern about this kind of thing is best left to people who don't need to look at metrics related to VCS activity to tell if someone is taking a hobby (or job) too far— trusted, close relations: family members, old friends, life partners, dear neighbors, etc.
That said, a lot of people in the Nix community go above and beyond what could reasonably be asked of them by others, and it probably does put them at risk of problems including burnout. I'd be interested in research into emotional well-being and F/OSS involvement in general, because it could be really valuable in informing strategies for building F/OSS sustainably and even personal advice for staying balanced.
At the individual level, though, concern about this kind of thing is best left to people who don't need to look at metrics related to VCS activity to tell if someone is taking a hobby (or job) too far— trusted, close relations: family members, old friends, life partners, dear neighbors, etc.
> trusted, close relations: family members, old friends, life partners, dear neighbors, etc.
Can we reasonably assume that somebody who pours themselves into open-source to the point of being visibly emotionally upset over the fact that somebody else made a package/service that goes in a direction you don't agree with most likely means you're sacrificing time otherwise spent in exactly what you mentioned: maintaining/having relationships with family members, old friends, life partners, etc.
How can you maintain a healthy social life + fitness life + professional career life if the bulk of your free time is spent caring so passionately about open source you're willing to argue/dedicate a ton of your free time to it?
I'm willing to bet people who operate at this level don't take care of themselves in at least one other area, whether it be non-PC-related relationships, fitness, social life, etc.
Can we reasonably assume that somebody who pours themselves into open-source to the point of being visibly emotionally upset over the fact that somebody else made a package/service that goes in a direction you don't agree with most likely means you're sacrificing time otherwise spent in exactly what you mentioned: maintaining/having relationships with family members, old friends, life partners, etc.
How can you maintain a healthy social life + fitness life + professional career life if the bulk of your free time is spent caring so passionately about open source you're willing to argue/dedicate a ton of your free time to it?
I'm willing to bet people who operate at this level don't take care of themselves in at least one other area, whether it be non-PC-related relationships, fitness, social life, etc.
Hello, the person you're speaking about here. I appreciate all the concern but I'm actually doing very good! While working on Nix was originally a hobby for me, I am now getting paid to do it, so it doesn't have to eat up any of my free time. I have healthy relationships with my family and friends, seeing people every weekend. And even if I'm not very good at it, I practice playing an instrument for about an hour every day and take lessons weekly!
I also want to mention that I usually don't argue much about issues. Most of my time is spent on making concrete improvements to the ecosystem :)
I also want to mention that I usually don't argue much about issues. Most of my time is spent on making concrete improvements to the ecosystem :)
I apologize that I overestimated how much time/effort it would take to contribute at the level you do to the point where I baselessly assumed other elements of your life were out of whack as a sacrifice. Thank you for all you do for the open source community.
Hello Infinisil! Your contributions to Nix are very appreciated. I am sorry you had to defend yourself against baseless speculation like above.
Argue a ton of your free time? Infinisil's post was about the same length as the one you just wrote, and considering you are engaging in more of an argument in this thread than he did in the posted thread, you better look yourself in the mirror. I think you owe Infinisil an apology.
As an outsider I’m super confused reading this discourse. There are a few people I consider O.G. Nix hackers in there.
edolstra isn’t some rando either, he’s behind (if I understand correctly) the original Nix paper all the way back in 2004: https://edolstra.github.io/pubs/nspfssd-lisa2004-final.pdf
edolstra isn’t some rando either, he’s behind (if I understand correctly) the original Nix paper all the way back in 2004: https://edolstra.github.io/pubs/nspfssd-lisa2004-final.pdf
Yeah, Eelco is the original author of Nix and continues to to maintain it.
I think all you're missing is my point. ;)
My point is not that it's automatically a huge deal whether Infinisil (or anyone) disapproves of this or that development in the community. But that nobody deserves to be dismissed with a backhanded I-hope-my-attempt-to-discredit-you-doesn't-discredit-you 'go touch grass' comment. And that I think within the Nix(OS) community there's basic neighborly recognition that is clearly missing here (on HN).
I think all you're missing is my point. ;)
My point is not that it's automatically a huge deal whether Infinisil (or anyone) disapproves of this or that development in the community. But that nobody deserves to be dismissed with a backhanded I-hope-my-attempt-to-discredit-you-doesn't-discredit-you 'go touch grass' comment. And that I think within the Nix(OS) community there's basic neighborly recognition that is clearly missing here (on HN).
Ah! I misunderstood your comment. I thought you meant the original post(s) on discourse were disrespectful.
Totally agree that “go touch grass” is a disrespectful take.
These are a bunch of O.G. hackers who’ve invested a portion of their life into a significantly underfunded problem statement in our industry.
They deserve respect and our industry is better for them spending their time the way they did.
I’m personally very thankful these folks exist and are as passionate as they are. It gives me hope that one day I’ll work with a package manager in production that does more than just YOLO unpack an archive file into a global namespace followed by some hopefully deterministic shell scripts.
Totally agree that “go touch grass” is a disrespectful take.
These are a bunch of O.G. hackers who’ve invested a portion of their life into a significantly underfunded problem statement in our industry.
They deserve respect and our industry is better for them spending their time the way they did.
I’m personally very thankful these folks exist and are as passionate as they are. It gives me hope that one day I’ll work with a package manager in production that does more than just YOLO unpack an archive file into a global namespace followed by some hopefully deterministic shell scripts.
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.
[0] https://nixos.wiki/wiki/Flakes
[0] https://nixos.wiki/wiki/Flakes
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.
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.
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.
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.
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 mental model about Nix is that it resembles make, but for the whole dependency graph.
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".
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".
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.
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.
Personally I think of Nix mainly as analogous to "the part of Docker which concerns itself with producing the OCI artefact", but in a much less cursed way than via Dockerfile and `docker build`. (`docker build` is inherently cursed by design; `nix build` is cursed only through incidental facts about Nix, and it would be possible in principle to write a non-cursed frontend for it.)
The nix PhD is titled "The Purely Functional Software Deployment Model", which suggests that deployment was very much in mind with Nix. https://edolstra.github.io/pubs/phd-thesis.pdf
That is very interesting. Skimming through the thesis, I find it fascinating introductory material to Nix. And you are correct, Nix started as a deployment tool. Although I'd argue in an era (1978!) when software are mostly distributed as source, reliable deployment largely implies reliable building from source.
1978 is not the publish date of the thesis. The examples (Firefox, JDK 5, OpenSSL 0.9.7) should give away that it's newer, and also the most recent citation is from 2006. I'm not sure why the title page has a 1978 as I can't read Dutch. Google Translate indicates it might be a date of birth of the author, but that's a weird thing for the title page.
> 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.
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.
nix.dev added a new tutorial for that recently: https://nix.dev/tutorials/learning-journey/packaging-existin...
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.
Great work from the Determinate Systems team!
Great work from the Determinate Systems team!
Are there plans to support uploads without github actions?
I would be interested in it if it didn't require github and github-specific configuations like github action workflows.
I would be interested in it if it didn't require github and github-specific configuations like github action workflows.
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.
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.
https://sourcehut.org/
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/
Thanks for sharing! We'll take a look. If nothing else, I'm sure you'll be able to publish using a CLI + token. Thanks!
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.
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.
Yep, that should work! Give it a try and let us know how it goes. Come join us on Discord, we'd be glad to chat about it.
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
We don’t want your proprietary Discord room—we want to see open options like an IRC chatroom, XMPP MUC, or Matrix Space.
What is Determinate Systems, the official group behind Nix? Not at all clear to me from the site: https://determinate.systems/
(Also, the support(?) phone number at the bottom seems pretty unusual!)
Just trying to get my head around, as a Nix-interested non-user (other than toying with it briefly years ago) what Flake is, who it's from, how important the controversy mentioned elsewhere is, if I should care, if I'm just starting whether I should use it or not, etc.
(Also, the support(?) phone number at the bottom seems pretty unusual!)
Just trying to get my head around, as a Nix-interested non-user (other than toying with it briefly years ago) what Flake is, who it's from, how important the controversy mentioned elsewhere is, if I should care, if I'm just starting whether I should use it or not, etc.
> (Also, the support(?) phone number at the bottom seems pretty unusual!)
Ok Zoomer. (Sorry couldn't resist)
So, old phones had letters on the digits (1 = ABC, 2 = DEF etc.) so you could have the phone number 555-GET-BEEF (555-438-2333) or whatever.
Christ I feel old.
Ok Zoomer. (Sorry couldn't resist)
So, old phones had letters on the digits (1 = ABC, 2 = DEF etc.) so you could have the phone number 555-GET-BEEF (555-438-2333) or whatever.
Christ I feel old.
No that's not what I mean, ha, I am aware of that. (Though it was never much of a thing in my non-US country, fwiw.) I meant having a phone number there struck me as unusual (for this sort of company/organisation).
My "old phones" had a rotary encoder with no letters in sight. Trrrrrrrak trak trrrak…
Flake utils as most people use it is often useless if not dangerous (leading users into errors you’ll now get bug reports for). To write a for loop over systems is 1–5 lines of Nix code instead of pulling in a dependency & it’s subdependencies. If you’re not testing systems, it might also not be wise to use defaultSystems & assuming it just works; often you are better served just picking the architectures you can test, or at least doing a union of the buildInputs’s support matrix.
Does it store artifacts or redirect to GitHub (or other) storage?
Good question. Publishing to FlakeHub makes an archive of the release, checks to make sure it evaluates cleanly in isolation, and publishes it to FlakeHub's storage.
This is to make sure that releases stay available in the long term, even through GitHub account renames or repository deletions.
This is to make sure that releases stay available in the long term, even through GitHub account renames or repository deletions.
For those who don’t know, edolstra (the person who posted this announcement on discourse) isn’t just some rando.
They’re behind the (I believe to be original) Nix paper back in 2004: https://edolstra.github.io/pubs/nspfssd-lisa2004-final.pdf
They’re behind the (I believe to be original) Nix paper back in 2004: https://edolstra.github.io/pubs/nspfssd-lisa2004-final.pdf
Not to be overly facetious, but if SemVer is so great, then why do we hash the content of inputs at all? Just hash the `major` and `minor` components of the version number, since `patch` updates do not change observable behavior and/or spacebar heating is not a thing.
SemVer is partly social and partly technical. -- Socially, with semver you're promising that the software (especially its interface) won't change too much. Technically, if function signatures change, or if implementation behaviour significantly changes (in ways that'd break old code), you want semver to indicate that.
Nix's hashing of inputs solves a different problem. It wants to make sure you can have slightly different builds of packages available to the system.
> ...since `patch` updates do not change observable behavior...
Sure, the social guarantee of semver isn't enough to guarantee reproducible packages the same way Nix does, sure. But that doesn't mean that someone depending on v1.1.1 of a package would be happy to suddenly see v2.0.0, or that they'd be unhappy to see v1.1.2.
Nix's hashing of inputs solves a different problem. It wants to make sure you can have slightly different builds of packages available to the system.
> ...since `patch` updates do not change observable behavior...
Sure, the social guarantee of semver isn't enough to guarantee reproducible packages the same way Nix does, sure. But that doesn't mean that someone depending on v1.1.1 of a package would be happy to suddenly see v2.0.0, or that they'd be unhappy to see v1.1.2.
i think i understand the problem this aims to solve, but why’s it a hosted web service instead of something more integrated into the traditional nix configuration system?
nix has plenty support for referring to data via git tags, seems like a flake-level semver solver could be implemented locally — even without blessing from mainline `nix` — so long as the flakes you use label their inputs/dependencies accordingly.
nix has plenty support for referring to data via git tags, seems like a flake-level semver solver could be implemented locally — even without blessing from mainline `nix` — so long as the flakes you use label their inputs/dependencies accordingly.
I agree with @Infinisil's assessment[1]. This seems to summuarize my Nix experience in the last two years. So many products "fixing Nix" with little to no effort to upstream any of it. As a Nix consumer, it's frustrating because every one of these projects I chose to adopt is basically playing a huge game of risk. I've already had at least a couple of them deprecated/abandoned on me.
Not saying it's a totally unique experience to Nix. It just seems especially concentrated at the moment.
[1]: https://discourse.nixos.org/t/introducing-flakehub/32044/3?u...
Not saying it's a totally unique experience to Nix. It just seems especially concentrated at the moment.
[1]: https://discourse.nixos.org/t/introducing-flakehub/32044/3?u...
Yeah it's less than ideal however FWIW graham's comments [1] seem to indicate that this project stemmed out of fairly rapid development over the course of a weekend with some additional time taken to polish it up.
If that's the case they may see this as some easy duct tape over top of flakes that could take the pain off of flakes itself while flakes actually work through the process of stabilizing.
[1] https://discourse.nixos.org/t/introducing-flakehub/32044/7
If that's the case they may see this as some easy duct tape over top of flakes that could take the pain off of flakes itself while flakes actually work through the process of stabilizing.
[1] https://discourse.nixos.org/t/introducing-flakehub/32044/7
That's largely right. Getting semver version solving into Nix core itself is a goal of ours. FlakeHub implements it server-side because landing it in Nix without proving it out conceptually would be really hard, and also -- in my opinion -- reckless. Trying these things out in the world without committing the project to it long term is a good thing.
I think there is a perception that if problems like that are first solved in a proprietary service rather than in core tools, it may in extension tie the ecosystem to that service, while at the same time lessen the need to solve problems in the foundation. Even if this perception is wrong, I think it exists and why you see concerns raised in this thread.
These are indeed valid concerns, and I think that it’s fair for the community to be vigilant about such things and to ask probing questions. But my perspective is both:
- Nothing we’re doing is inherently proprietary or "secret sauce". FlakeHub isn’t doing anything magical, and the version solving feature would be better if Nix did it itself.
- Also, proprietary services can serve important functions in OSS communities. They can expand the user base significantly (like GitHub to Git) and they can send signals to maintainers of official tools about what’s a hit and what’s a dud. And I think that that’s precisely what we’re doing not just with FlakeHub but also with the Determinate Nix Installer, the Magic Nix Cache, the Flake Checker, and others.
- Nothing we’re doing is inherently proprietary or "secret sauce". FlakeHub isn’t doing anything magical, and the version solving feature would be better if Nix did it itself.
- Also, proprietary services can serve important functions in OSS communities. They can expand the user base significantly (like GitHub to Git) and they can send signals to maintainers of official tools about what’s a hit and what’s a dud. And I think that that’s precisely what we’re doing not just with FlakeHub but also with the Determinate Nix Installer, the Magic Nix Cache, the Flake Checker, and others.
I really want to think the best of DetSys, and I use some of their work and love it. Some people who work at DetSys have been prolific contributors in the Nix community as long as I can remember. I also understand the urge (and precedent, within the Nix community) to go off and build your own thing to experiment.
But I think with the general pain and anxiety many longstanding community members are feeling over increasing commercial investment in Nix as well as the whole design and rollout of flakes, more upstream-first development would go a long way (as would quickly making good on statements of interest to upstream these features).
But I think with the general pain and anxiety many longstanding community members are feeling over increasing commercial investment in Nix as well as the whole design and rollout of flakes, more upstream-first development would go a long way (as would quickly making good on statements of interest to upstream these features).
I know folks have anxieties about commercial investment, and anxieties about developing flakes. Whenever we hit bugs in flakes, we go work upstream to fix them. We do this rather often :).
I won't try to persuade you one way or another on commercial investment other than it is here with or without DetSys, and we've released a rather large suite of tools to make using Nix more pleasant and all but one (flakehub's backend) is free and open source. I feel that is a good way to go!
I also think developing features and improvements to Nix outside of it is a good way to prove out ideas that can be eventually merged in to core. We don't _want_ to be solving the version on the server, but I'm rather sure it would have taken months if not years to get an experiment merged. And for good reason: we all want to make sure what goes in to Nix is solid.
I won't try to persuade you one way or another on commercial investment other than it is here with or without DetSys, and we've released a rather large suite of tools to make using Nix more pleasant and all but one (flakehub's backend) is free and open source. I feel that is a good way to go!
I also think developing features and improvements to Nix outside of it is a good way to prove out ideas that can be eventually merged in to core. We don't _want_ to be solving the version on the server, but I'm rather sure it would have taken months if not years to get an experiment merged. And for good reason: we all want to make sure what goes in to Nix is solid.
> I also think developing features and improvements to Nix outside of it is a good way to prove out ideas that can be eventually merged in to core.
I think it definitely can be. Naturally, more DetSys code and ideas that go through that whole journey, the more likely Nixers will be to reflexively trust the company when it comes to new projects. I'm optimistic that that can turn out well.
> we've released a rather large suite of tools to make using Nix more pleasant and all but one (flakehub's backend) is free and open source. I feel that is a good way to go!
I think open-core and proprietary services based on F/OSS can be an effective business model that helps get valuable open-source work done.
For me, Red Hat's model and Qt-style dual licensing are even more attractive because they are based on comprehensive F/OSS licensing.
That said, companies have to figure out licensing strategies that make sense for them and the particular markets and software they're dealing with. I don't begrudge, e.g., Determinate Systems or Cachix or Hercules taking up strategies that involve proprietary services because I've seen people involved with all three companies continue to make important contributions to Nix, Nixpkgs, and F/OSS tooling in the ecosystem that's about more than just plugging into those services. That signals good faith engagement to me.
But seeing stuff like version management get handled in bespoke ways in proprietary services like FlakeHub or at Flox when it remains unaddressed in Nix itself naturally raises an alarm, though.
> We don't _want_ to be solving the version on the server,
I feel like that's good sense architecturally.
Seeing this problem solved in Nix itself will help establish a record and reputation.
I think it definitely can be. Naturally, more DetSys code and ideas that go through that whole journey, the more likely Nixers will be to reflexively trust the company when it comes to new projects. I'm optimistic that that can turn out well.
> we've released a rather large suite of tools to make using Nix more pleasant and all but one (flakehub's backend) is free and open source. I feel that is a good way to go!
I think open-core and proprietary services based on F/OSS can be an effective business model that helps get valuable open-source work done.
For me, Red Hat's model and Qt-style dual licensing are even more attractive because they are based on comprehensive F/OSS licensing.
That said, companies have to figure out licensing strategies that make sense for them and the particular markets and software they're dealing with. I don't begrudge, e.g., Determinate Systems or Cachix or Hercules taking up strategies that involve proprietary services because I've seen people involved with all three companies continue to make important contributions to Nix, Nixpkgs, and F/OSS tooling in the ecosystem that's about more than just plugging into those services. That signals good faith engagement to me.
But seeing stuff like version management get handled in bespoke ways in proprietary services like FlakeHub or at Flox when it remains unaddressed in Nix itself naturally raises an alarm, though.
> We don't _want_ to be solving the version on the server,
I feel like that's good sense architecturally.
Seeing this problem solved in Nix itself will help establish a record and reputation.
I will try to put myself as an outsider and just reflect on what I see. We have a very innovative Linux distribution / packaging etc software, where there is no dominant commercial actor. Instead there are a number of smaller companies specializing in evolving the ecosystem, selling services around it and so on. There is opportunity in Nix future for a commercial actor to make a lot of money by becoming the most trusted authority in aspects of it. Becoming the next Red Hat or something like that. I sense there is a lot of positioning and hustling to become THE Nix company that takes pole position and becomes the dominant one.
Once in a while, there have been an announcement like this, which has not been well received. I am a little worried about it, and what it can lead to for the future. I worry it can split the community and be harmful to the future of very innovative software. I am trying to think of a similar situation within another area of the Linux or Open Source space, but can't really come up with good examples.
Interested to hear if these thoughts are well founded or just a bad take.
Once in a while, there have been an announcement like this, which has not been well received. I am a little worried about it, and what it can lead to for the future. I worry it can split the community and be harmful to the future of very innovative software. I am trying to think of a similar situation within another area of the Linux or Open Source space, but can't really come up with good examples.
Interested to hear if these thoughts are well founded or just a bad take.
We strongly value open source software through and through, and have a team of long term contributors to open-source projects and communities. Part of open source is being allowed to build and experiment and see what happens. I find it unfortunate that people respond so strongly to our work, but I think part of it is a bit of fear of the unknown. We’ve published a lot of tools that we think are really nice, and almost all of them are totally open source and free (though the flakehub.com backend currently is not). Hopefully in the end the proof is in the pudding.
It seems like the Nix community is already headed towards a soft fork. DetSys already provides their own Nix installer, and now FlakeHub. Jetpack has Devbox, which is an entirely different interface over flakes.
I’m no Nix expert but I’ve used it enough to know that the hype exceeds the capabilities and especially the UX of the tool currently. (Just as an example, pinning versions that aren’t in the current nixpkgs release isn’t even possible right now without resorting to overlays and other hacks.) Frankly I’m glad that people are working to make it more user friendly. It reminds me a lot of when I first tried Stack for Haskell: packages just worked out of the box, no more tracking down arcane cabal-install errors and figuring out why it didn’t build in my machine.
I’m no Nix expert but I’ve used it enough to know that the hype exceeds the capabilities and especially the UX of the tool currently. (Just as an example, pinning versions that aren’t in the current nixpkgs release isn’t even possible right now without resorting to overlays and other hacks.) Frankly I’m glad that people are working to make it more user friendly. It reminds me a lot of when I first tried Stack for Haskell: packages just worked out of the box, no more tracking down arcane cabal-install errors and figuring out why it didn’t build in my machine.
> DetSys already provides their own Nix installer
That installer has actually been developed with community collaboration from outside DetSys from early on in its lifecycle via the Nix Installer Working Group¹, which includes stakeholders from other companies and whoever else volunteered to get involved.
I haven't followed it super closely recently, but to the best of my knowledge DetSys has done a good job with that project of orienting themselves towards the wider community and upstreaming that work.
FWIW, the maintainer of and chief contributor to that project is also extremely responsive to community activity on GitHub as well. I reported a few bugs the other day and was frankly delighted by how it went. It's being developed in the open, like proper open-source. The Determinate Nix Installer is not at all a 'let's do this in-house, behind closed doors, then throw it over the fence' kind of effort.
--
1: https://discourse.nixos.org/t/nix-installer-workgroup/21495/...
That installer has actually been developed with community collaboration from outside DetSys from early on in its lifecycle via the Nix Installer Working Group¹, which includes stakeholders from other companies and whoever else volunteered to get involved.
I haven't followed it super closely recently, but to the best of my knowledge DetSys has done a good job with that project of orienting themselves towards the wider community and upstreaming that work.
FWIW, the maintainer of and chief contributor to that project is also extremely responsive to community activity on GitHub as well. I reported a few bugs the other day and was frankly delighted by how it went. It's being developed in the open, like proper open-source. The Determinate Nix Installer is not at all a 'let's do this in-house, behind closed doors, then throw it over the fence' kind of effort.
--
1: https://discourse.nixos.org/t/nix-installer-workgroup/21495/...
Oh yeah, I have no criticisms with how that project is being run. But obviously they still decided to launch it instead of working to upstream it.
Point of clarification: we are fully open to upstreaming the installer in whole or in part and have been from the get-go.[^1] But the installer is a pretty radical departure from the current official installer. The official installer is written in Bash; the DetSys installer is written in Rust. The official installer targets fairly "standard" platforms; the DetSys installer has experimental support for things like the SteamDeck. And so on.
We think it's perfectly okay to have that kind of distribution of labor in OSS, where core/upstream things need to be extremely stable and conservative while the community runs experiments and figures out what works and doesn't.
[1]: https://determinate.systems/posts/determinate-nix-installer#...
We think it's perfectly okay to have that kind of distribution of labor in OSS, where core/upstream things need to be extremely stable and conservative while the community runs experiments and figures out what works and doesn't.
[1]: https://determinate.systems/posts/determinate-nix-installer#...
The default installer doesn't even support uninstalling Nix, which was a real pain when I tried to do so.
> We think it's perfectly okay to have that kind of distribution of labor in OSS, where core/upstream things need to be extremely stable and conservative while the community runs experiments and figures out what works and doesn't.
I hope nothing I said suggested I didn't think this was ok. I really appreciate that the DetSys installer exists. I'm just not sure why anyone would use the default installer given that it does.
> We think it's perfectly okay to have that kind of distribution of labor in OSS, where core/upstream things need to be extremely stable and conservative while the community runs experiments and figures out what works and doesn't.
I hope nothing I said suggested I didn't think this was ok. I really appreciate that the DetSys installer exists. I'm just not sure why anyone would use the default installer given that it does.
> I’m no Nix expert but I’ve used it enough to know that the hype exceeds the capabilities and especially the UX of the tool currently.
Nix has a higher difficulty curve, and rougher corners, than most tools out there.
The onboarding experience can vary from "wow that was easy, this is incredible" to "this is easy to do with Linux, but why is this difficult on NixOS?".
Nevertheless, Nix is a much more powerful tool for dealing with packages compared to what's widely used today. I don't think "overhyped" is deserved, even though someone new to nix will likely have difficulty trying to use it for everything.
> Just as an example, pinning versions that aren’t in the current nixpkgs release isn’t even possible right now without resorting to overlays and other hacks
I read this as "package foo v1.1 was in nixpkgs at some point, but's now foo v1.2". Not sure I'd use the term "hacks", but there are several ways you'd be able to refer to a v1.1 package, depending on what you're trying to do.
But, yeah, if you want a different version than one that's provided by someone else, you're going to have to come up with something yourself.
Nix has a higher difficulty curve, and rougher corners, than most tools out there.
The onboarding experience can vary from "wow that was easy, this is incredible" to "this is easy to do with Linux, but why is this difficult on NixOS?".
Nevertheless, Nix is a much more powerful tool for dealing with packages compared to what's widely used today. I don't think "overhyped" is deserved, even though someone new to nix will likely have difficulty trying to use it for everything.
> Just as an example, pinning versions that aren’t in the current nixpkgs release isn’t even possible right now without resorting to overlays and other hacks
I read this as "package foo v1.1 was in nixpkgs at some point, but's now foo v1.2". Not sure I'd use the term "hacks", but there are several ways you'd be able to refer to a v1.1 package, depending on what you're trying to do.
But, yeah, if you want a different version than one that's provided by someone else, you're going to have to come up with something yourself.
> Not sure I'd use the term "hacks", but there are several ways you'd be able to refer to a v1.1 package, depending on what you're trying to do.
Yeah, this is the part I find a bit silly. There should be one way to do this. What I want to do is pin an Erlang version (down to semver patch) and then pin an Elixir version that’s compatible with it (also to semver patch). This is trivial to do with my existing tools (asdf/rtx and Dockerfiles), but it doesn’t have first-class support in Nix. I have to build that capability myself! I was absolutely floored by this after hearing so much about how seriously Nix takes reproducibility.
Similarly, the default Elixir and Erlang packages don’t even have a version, you have to use one of the special elixir_1_14 packages to get a specific minor version. The default Elixir just gets the latest release at the time nixpkgs was released. I can pin nixpkgs trivially but it’s not intuitive to pin individual packages across nixpkgs releases. Clearly this is just how Nix works, but because it’s not how any other dependency managers work, it’s a lot harder to integrate piecemeal.
edit: to Jetpack’s credit, this is one of the things I really like about Devbox. It makes pinning minor versions easy!
Yeah, this is the part I find a bit silly. There should be one way to do this. What I want to do is pin an Erlang version (down to semver patch) and then pin an Elixir version that’s compatible with it (also to semver patch). This is trivial to do with my existing tools (asdf/rtx and Dockerfiles), but it doesn’t have first-class support in Nix. I have to build that capability myself! I was absolutely floored by this after hearing so much about how seriously Nix takes reproducibility.
Similarly, the default Elixir and Erlang packages don’t even have a version, you have to use one of the special elixir_1_14 packages to get a specific minor version. The default Elixir just gets the latest release at the time nixpkgs was released. I can pin nixpkgs trivially but it’s not intuitive to pin individual packages across nixpkgs releases. Clearly this is just how Nix works, but because it’s not how any other dependency managers work, it’s a lot harder to integrate piecemeal.
edit: to Jetpack’s credit, this is one of the things I really like about Devbox. It makes pinning minor versions easy!
I think DevBox make use of an index where it shows the nixpkgs version for different versions of different software. https://www.nixhub.io/packages/erlang
Note that this approach isn't without its downsides (compared to overriding the version in nixpkgs, or using a separate nix package). -- Mainly, since it uses an older nixpkgs version, the dependencies will also be that old version. (They won't have any security fixes which have been released since then; and it'll take up more disk space to install).
> Similarly, the default Elixir and Erlang packages don’t even have a version, you have to use one of the special elixir_1_14 packages to get a specific minor version.
Supporting multiple versions be more helpful at the cost of more effort to maintain. It's a reasonable tradeoff that nixpkgs provides the latest, and if you want anything other than what nixpkgs provides, you write some nix for that.
Note that this approach isn't without its downsides (compared to overriding the version in nixpkgs, or using a separate nix package). -- Mainly, since it uses an older nixpkgs version, the dependencies will also be that old version. (They won't have any security fixes which have been released since then; and it'll take up more disk space to install).
> Similarly, the default Elixir and Erlang packages don’t even have a version, you have to use one of the special elixir_1_14 packages to get a specific minor version.
Supporting multiple versions be more helpful at the cost of more effort to maintain. It's a reasonable tradeoff that nixpkgs provides the latest, and if you want anything other than what nixpkgs provides, you write some nix for that.
> I think DevBox make use of an index where it shows the nixpkgs version for different versions of different software
Correct.
> It's a reasonable tradeoff that nixpkgs provides the latest, and if you want anything other than what nixpkgs provides, you write some nix for that.
Reasonable for you, maybe. For me, I have dozens of Erlang projects on various versions that I don’t want to break to start using Nix, and Nix is significantly more effort to get a reproducible configuration than my current setup. Why bother? In what universe is it reasonable to make package consumers write software to consume different versions of a package? Tools are supposed to make our lives easier, not harder.
Correct.
> It's a reasonable tradeoff that nixpkgs provides the latest, and if you want anything other than what nixpkgs provides, you write some nix for that.
Reasonable for you, maybe. For me, I have dozens of Erlang projects on various versions that I don’t want to break to start using Nix, and Nix is significantly more effort to get a reproducible configuration than my current setup. Why bother? In what universe is it reasonable to make package consumers write software to consume different versions of a package? Tools are supposed to make our lives easier, not harder.
> In what universe is it reasonable to make package consumers write software...
Docker is also a tool where the UX is nicer if you write code (e.g. a Dockerfile) rather than using cli only (e.g. `docker commit`).
I don't think there's anyone who would prefer to use `docker commit` instead of using a Dockerfile.
With Nix, it's similar: only using Nix through the CLI, and not writing Nix code, is going to limit how useful Nix is.
In any case, you don't need to write Nix code to use a package from an older revision of nixpkgs. -- With different options, there are different trade-offs.
> Nix is significantly more effort to get a reproducible configuration than my current setup. Why bother? ... Tools are supposed to make our lives easier, not harder.
Yeah, Nix is much more difficult to use than other tools.
Nix's UX is one where you pay a big cost upfront in order to save on effort later.
e.g. that's comparable in Infra-as-Code, where writing Terraform is going to be slower than just managing stuff through a graphical console.
Docker is also a tool where the UX is nicer if you write code (e.g. a Dockerfile) rather than using cli only (e.g. `docker commit`).
I don't think there's anyone who would prefer to use `docker commit` instead of using a Dockerfile.
With Nix, it's similar: only using Nix through the CLI, and not writing Nix code, is going to limit how useful Nix is.
In any case, you don't need to write Nix code to use a package from an older revision of nixpkgs. -- With different options, there are different trade-offs.
> Nix is significantly more effort to get a reproducible configuration than my current setup. Why bother? ... Tools are supposed to make our lives easier, not harder.
Yeah, Nix is much more difficult to use than other tools.
Nix's UX is one where you pay a big cost upfront in order to save on effort later.
e.g. that's comparable in Infra-as-Code, where writing Terraform is going to be slower than just managing stuff through a graphical console.
Every piece of technology is incapable of doing anything if you label all solutions as "hacks."
Here's proof:
Is it possible to write C programs that manipulate strings? No, because string library functions are "hacks." Is it possible to write a bash script that passes arguments with spaces to a command? No, because quoting and character escaping are "hacks."
Nix packages are malleable. With a bit of code, customizations can be applied to individual packages and entire dependency closures alike. An overlay is an embodiment of this property. It allows the user to create packages that fits their unique needs on the fly without having to repackage the whole world. No other package manager maybe besides Guix has this capability. I don't think it's fair to dismiss it as an "hack."
Here's proof:
Is it possible to write C programs that manipulate strings? No, because string library functions are "hacks." Is it possible to write a bash script that passes arguments with spaces to a command? No, because quoting and character escaping are "hacks."
Nix packages are malleable. With a bit of code, customizations can be applied to individual packages and entire dependency closures alike. An overlay is an embodiment of this property. It allows the user to create packages that fits their unique needs on the fly without having to repackage the whole world. No other package manager maybe besides Guix has this capability. I don't think it's fair to dismiss it as an "hack."
Me too. Several teams are trying to land grab by "wrapping" Nix with extra stuff.
But as good as flakes are, they still have big problems. flake.lock size explosion, UI hassles, no cross compiling support.
But as good as flakes are, they still have big problems. flake.lock size explosion, UI hassles, no cross compiling support.
[deleted]
I'm always excited to see developments in the Nix ecosystem, but I can't help but feel that this is a little bit tone-deaf. Nix flakes is a sensitive topic in the Nix community. Instead of spending time gracefully stabilizing the currently experimental feature, some of the core contributors to Nix apparently feel that doubling down and building a product on top of it instead is a better way to spend time.
In addition, we're invited to join the discussion on Discord, of all places, instead of the other two standard messaging platforms that the Nix community typically uses (Matrix and IRC)
In addition, we're invited to join the discussion on Discord, of all places, instead of the other two standard messaging platforms that the Nix community typically uses (Matrix and IRC)
> I'm always excited to see developments in the Nix ecosystem, but I can't help but feel that this is a little bit tone-deaf. Nix flakes is a sensitive topic in the Nix community. Instead of spending time gracefully stabilizing the currently experimental feature, some of the core contributors to Nix apparently feel that doubling down and building a product on top of it instead is a better way to spend time.
Eh, they had a pain-point, built a tool to alleviate it, and shared it. I suppose the less tone-deaf alternatives are "keep feeling the pain (by not building it)" or "let everybody else keep feeling the pain (by not sharing it)." I can't complain too much with that.
> In addition, we're invited to join the discussion on Discord, of all places, instead of the other two standard messaging platforms that the Nix community typically uses (Matrix and IRC)
100% with you on this point.
Eh, they had a pain-point, built a tool to alleviate it, and shared it. I suppose the less tone-deaf alternatives are "keep feeling the pain (by not building it)" or "let everybody else keep feeling the pain (by not sharing it)." I can't complain too much with that.
> In addition, we're invited to join the discussion on Discord, of all places, instead of the other two standard messaging platforms that the Nix community typically uses (Matrix and IRC)
100% with you on this point.
As someone who is not listening in on the flake stabilization process, and who just wants to use Nix my thinking is, what's the alternative? To me it looks like people can either build on the feature that exists now, or put plans on hold for who knows how long while getting by with some lesser solution, passing up public enthusiasm that could be directed to growing the Nix ecosystem in the meantime.
I'm getting the hint that some people aren't happy with the current state of flakes. But right now it's the best solution for a certain large class of problems so it's what people are going to go with. Again, as a relative outsider I see flakes as The Way Nix Works with the requirement of enabling experimental features just being a part of the Nix process. Nix is rapidly growing in popularity with a lot of people drawing the same conclusion as me. Maybe there is a better alternative to flakes in the horizon, and when it's ready I'll consider switching. But I'm not going to wait to use Nix in the meantime, and for me the best way to use Nix currently is flakes.
I'm getting the hint that some people aren't happy with the current state of flakes. But right now it's the best solution for a certain large class of problems so it's what people are going to go with. Again, as a relative outsider I see flakes as The Way Nix Works with the requirement of enabling experimental features just being a part of the Nix process. Nix is rapidly growing in popularity with a lot of people drawing the same conclusion as me. Maybe there is a better alternative to flakes in the horizon, and when it's ready I'll consider switching. But I'm not going to wait to use Nix in the meantime, and for me the best way to use Nix currently is flakes.
In our opinion, flakes are the future of Nix and we're doing the hard work of using them extensively everywhere we can. While we do that, we fix bugs and papercuts along the way. I don't think flakes _can_ meaningfully stabilize without people pushing them to their boundaries and then addressing the problems that come up.
In other words, yes: we are doubling down because we don't see a future of Nix where flakes or something like them aren't central.
In other words, yes: we are doubling down because we don't see a future of Nix where flakes or something like them aren't central.
you guys seem very <ahem>, determined, to do things your way. I'm kinda new to the whole nix community and it just feels like you guys are a bull in a china shop. Maybe that's what it needs. Strong, opinionated, decisive, leadership. Dunno. All I can say is I hope, I _really_ hope, that you guys don't become, basically, Nix's "google". Defacto owning it to all of our costly detriment over time. It's why I'm tempted, despite their polish, to stay away from your products for the time being.
Honestly, after seeing a little bit of how the sausage gets made and where the gridlock in Nix comes from, I think that's kind of needed.
My feeling is we’ve been careful and considered about what we build and why, though I understand some folks don’t like what we’ve made. That’s their right, just like it is our right to build things we think are important and add value to the Nix community. We’re not in charge of the Nix project: Nix has its own governance and processes that we also engage with.
Most of our tools are open source, totally free, and don’t depend on us as a company continuing to exist. In many cases I hope the Nix project wants to adopt and take over some of our work — like the installer.
Our goal is to make Nix as good as possible, and do it together. In the meantime, it’s okay to not use our tools :)
Most of our tools are open source, totally free, and don’t depend on us as a company continuing to exist. In many cases I hope the Nix project wants to adopt and take over some of our work — like the installer.
Our goal is to make Nix as good as possible, and do it together. In the meantime, it’s okay to not use our tools :)
[deleted]
> 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