# A call for the Nix team to present a unified front on the outcome and strategy around Nix flakes
**URL:** https://discourse.nixos.org/t/a-call-for-the-nix-team-to-present-a-unified-front-on-the-outcome-and-strategy-around-nix-flakes/54959
**Category:** Nix
**Created:** [October 26, 2024, 12:18am UTC](https://discourse.nixos.org/t/a-call-for-the-nix-team-to-present-a-unified-front-on-the-outcome-and-strategy-around-nix-flakes/54959 "2024-10-26T00:18:27Z")
**Posts on this page:** 20
**Page:** 2
### Author:  [@waffle8946](https://discourse.nixos.org/u/waffle8946)
#### Post date: [October 26, 2024, 4:18pm UTC](https://discourse.nixos.org/t/a-call-for-the-nix-team-to-present-a-unified-front-on-the-outcome-and-strategy-around-nix-flakes/54959/22 "2024-10-26T16:18:34Z")
I wouldn’t say non-flakes are good either. And they are much better officially documented compared to flakes. Flakes do not have good documentation in any official sense, all the good info comes from blog posts and such.
Like I was getting at, both path-based and flake-based nix are not-great and I ended up leaving nix.
---
### Author:  [@Balssh](https://discourse.nixos.org/u/Balssh)
#### Post date: [October 26, 2024, 4:23pm UTC](https://discourse.nixos.org/t/a-call-for-the-nix-team-to-present-a-unified-front-on-the-outcome-and-strategy-around-nix-flakes/54959/23 "2024-10-26T16:23:20Z")
I consider blog posts and such documentation too, as I can refer to them when trying things out. Of course, something like the Archwiki would’ve been ideal, but in this regard, I struggled to find much good examples of path-based configs so I stuck with what I could easily refer to more: flakes.
If you don’t mind, what did you went with instead of nix?
---
### Author:  [@nyanbinary](https://discourse.nixos.org/u/nyanbinary)
#### Post date: [October 26, 2024, 4:46pm UTC](https://discourse.nixos.org/t/a-call-for-the-nix-team-to-present-a-unified-front-on-the-outcome-and-strategy-around-nix-flakes/54959/24 "2024-10-26T16:46:41Z")
Flakes are fundamentally broken.
> **[Flakes aren't real and cannot hurt you: a guide to using Nix flakes the...](https://jade.fyi/blog/flakes-arent-real/)**
>
> computers i guess
[https://samuel.dionne-riel.com/blog/2023/09/06/flakes-is-an-experiment-that-did-too-much-at-once.html](https://samuel.dionne-riel.com/blog/2023/09/06/flakes-is-an-experiment-that-did-too-much-at-once.html)
(I say this as a person who uses flakes, by the way)
---
### Author:  [@misuzu](https://discourse.nixos.org/u/misuzu)
#### Post date: [October 26, 2024, 5:08pm UTC](https://discourse.nixos.org/t/a-call-for-the-nix-team-to-present-a-unified-front-on-the-outcome-and-strategy-around-nix-flakes/54959/26 "2024-10-26T17:08:23Z")
For me flakes solve the pinning problem while keeping convenient UI, but the way it’s internally implemented is horrible.
Using flakes for anything other than NixOS configurations is really bad experience, the obvious example is trying to build something in a nixpkgs tree - the entire nixpkgs checkout is copied to the nix store every single time! Just why tf is it doing it, why it couldn’t do things the way regular nix-build does?
---
### Author:  [@grahamc](https://discourse.nixos.org/u/grahamc)
#### Post date: [October 26, 2024, 5:12pm UTC](https://discourse.nixos.org/t/a-call-for-the-nix-team-to-present-a-unified-front-on-the-outcome-and-strategy-around-nix-flakes/54959/27 "2024-10-26T17:12:54Z")
> [@samueldr](#):
>
> And with snark: and on top of that, Determinate Systems won’t have to bully the Nix project into making ~~fetch~~ Flakes happen.
Again, at this point I’m hoping the Nix team makes a clear choice here. Say one way or another. The current status of a semi-vague to-do list and fellow members suggesting it be deleted is the worst scenario to be in.
---
### Author:  [@samueldr](https://discourse.nixos.org/u/samueldr)
#### Post date: [October 26, 2024, 5:18pm UTC](https://discourse.nixos.org/t/a-call-for-the-nix-team-to-present-a-unified-front-on-the-outcome-and-strategy-around-nix-flakes/54959/28 "2024-10-26T17:18:05Z")
I think we’re in agreement then.
I give you the authorization: carve out the Flakes implementation into your own plugin, which disables the `--experimental` flag for flakes, and work with the Nix team into adding the generic interfaces from which everyone will benefit into the plugin system.
Nothing will happen if you don’t make any move. Especially since, as you point it out, the Nix team is (at best) indecisive around the Flakes situation. They surely won’t take the time to migrate it into a plugin if (like you’re implying) they intend to remove it.
Now is the time to ensure this removal/migration happens smoothly for Flakes users. Now is the time to free the Nix team from the burden. Work _with_ them, not against them.
---
### Author:  [@srd424](https://discourse.nixos.org/u/srd424)
#### Post date: [October 26, 2024, 5:18pm UTC](https://discourse.nixos.org/t/a-call-for-the-nix-team-to-present-a-unified-front-on-the-outcome-and-strategy-around-nix-flakes/54959/29 "2024-10-26T17:18:42Z")
> [@samueldr](#):
>
> Anyways, I’ve said it from pretty much the start that Flakes should have been implemented through a Nix plugin. That it is the most pitiful excuse to say that the plugin system cannot accommodate Flakes. If it cannot, it means the plugin system is incomplete for other potential uses of the plugin system.
>
> That’s it. Just do it. I personally give you permission to do it. Fork Flakes off.
This honestly doesn’t feel like an insane idea. I still after a year consider myself a nix newbie, I’ve used flakes in a few places where it seemed sensible, and also to work with other flakes, but even I have run up a few situations where they’re just added complexity or have missing features.
Moving as much of the flake handling as possible to a plugin, or a wrapper command, or something, feels like it might be the option that attracts the least amount of collective loathing. If a plugin is used, expand the interface (or create a new one) at will to allow this…?
I’m wondering if the Lix folks have thought about this - while I know they are focused on increment changes so far, they also seem to be the ones most prepared to consider longer term architectural changes…?
---
### Author:  [@johnkyle](https://discourse.nixos.org/u/johnkyle)
#### Post date: [October 26, 2024, 5:20pm UTC](https://discourse.nixos.org/t/a-call-for-the-nix-team-to-present-a-unified-front-on-the-outcome-and-strategy-around-nix-flakes/54959/30 "2024-10-26T17:20:48Z")
> [@waffle8946](#):
>
> both path-based and flake-based nix are not-great
> [@misuzu](#):
>
> For me flakes solve the pinning problem while keeping convenient UI, but the way it’s internally implemented is horrible.
I’m wondering, what’s wrong with using niv for pinning and building with NixOS modules, aka the “Classic Nix” mode? I’m asking because I haven’t used niv for a real project yet, so I don’t know what sharp edges may be there. It seems perfect for filling this need without bringing along additional problems.
---
### Author:  [@ElvishJerricco](https://discourse.nixos.org/u/ElvishJerricco)
#### Post date: [October 26, 2024, 5:21pm UTC](https://discourse.nixos.org/t/a-call-for-the-nix-team-to-present-a-unified-front-on-the-outcome-and-strategy-around-nix-flakes/54959/31 "2024-10-26T17:21:56Z")
I will say, my personal opinion is that forking off flakes would be a bad move. I’ve drawn the comparison to the old Haskell days with Stack before, and this would be another example of reliving that old experience. When Stack became a separate tool with its own package repo and ecosystem, every single problem that was already present in the community was exacerbated and turned up to 11.
@grahamc That isn’t to say I approve of your rampant use of the Nix ecosystem as if it’s DetSys’s own product (see: yesterday’s blog post in which most of the links to community-wide terms like NixOS and nixpkgs were links to your site). But I do think it’s better to work together.
---
### Author:  [@samrose](https://discourse.nixos.org/u/samrose)
#### Post date: [October 26, 2024, 5:23pm UTC](https://discourse.nixos.org/t/a-call-for-the-nix-team-to-present-a-unified-front-on-the-outcome-and-strategy-around-nix-flakes/54959/32 "2024-10-26T17:23:47Z")
I’ve used nix since around 2017. Before flakes, I already considered nix to have some rough edges. People active in Nix in 2017 or so confirmed to me that Nix probably could benefit from improvements on multiple fronts. Never the less, for me, Nix worked well 99% of the time or more. I started using Flakes in 2021 and the same thing applies there too.
Where are people having productive discussions in the nix community about improving nix, or flakes, where multiple people tend reach consensus, and create a plan to improve the overall quality?
---
### Author:  [@srd424](https://discourse.nixos.org/u/srd424)
#### Post date: [October 26, 2024, 5:24pm UTC](https://discourse.nixos.org/t/a-call-for-the-nix-team-to-present-a-unified-front-on-the-outcome-and-strategy-around-nix-flakes/54959/33 "2024-10-26T17:24:21Z")
> [@johnkyle](#):
>
> I’m wondering, what’s wrong with using niv for pinning and building with NixOS modules, aka the “Classic Nix” mode? I’m asking because I haven’t used niv for a real project yet, so I don’t know what sharp edges may be there. It seems perfect for filling this need without bringing along additional problems.
I’ve used npins for a lot of things and really liked the simplicity, but not for actual system configs yet - it is definitely on the to-do list though.
---
### Author:  [@nyanbinary](https://discourse.nixos.org/u/nyanbinary)
#### Post date: [October 26, 2024, 5:30pm UTC](https://discourse.nixos.org/t/a-call-for-the-nix-team-to-present-a-unified-front-on-the-outcome-and-strategy-around-nix-flakes/54959/34 "2024-10-26T17:30:21Z")
> [@srd424](#):
>
> I’m wondering if the Lix folks have thought about this - while I know they are focused on increment changes so far, they also seem to be the ones most prepared to consider longer term architectural changes…?
> **[Nix lang v2 | Lix Wiki](https://wiki.lix.systems/books/lix-contributors/page/nix-lang-v2)**
>
> The Nix language unfortunately is full of little and big design accidents. Only so much can be fixed...
Lix has this :3
---
### Author:  [@samrose](https://discourse.nixos.org/u/samrose)
#### Post date: [October 26, 2024, 5:30pm UTC](https://discourse.nixos.org/t/a-call-for-the-nix-team-to-present-a-unified-front-on-the-outcome-and-strategy-around-nix-flakes/54959/35 "2024-10-26T17:30:32Z")
I used niv right before flakes, but found it more to my taste to just
```auto
let
bootstrap = import {};
in
bootstrap.fetchFromGitHub {
owner = "NixOS";
repo = "nixpkgs";
rev = "";
sha256 = "thesha";
}
# default.nix
let
nixpkgs = import ./nixpkgs.nix;
pkgs = import nixpkgs {};
in
```
or sometimes
```nix
let
pkgs = import (fetchFromGitHub {
owner = "NixOS";
repo = "nixpkgs";
rev = "4ecab3273592f27479a583fb6d975d4aba3486fe";
sha256 = "0v5l6c8bvf9ls3dxwc9mg6fw9ak7wzcj";
}) {};
in
```
edited: however I like flakes better than this approach
---
### Author:  [@samrose](https://discourse.nixos.org/u/samrose)
#### Post date: [October 26, 2024, 5:32pm UTC](https://discourse.nixos.org/t/a-call-for-the-nix-team-to-present-a-unified-front-on-the-outcome-and-strategy-around-nix-flakes/54959/36 "2024-10-26T17:32:21Z")
Lix is great work. I haven’t had time to contrib, but I am still trying to find ways to use it and offer whatever feedback I can that is seen as valuable. It was certainly simple to build from source the last time I tried.
---
### Author:  [@misuzu](https://discourse.nixos.org/u/misuzu)
#### Post date: [October 26, 2024, 5:43pm UTC](https://discourse.nixos.org/t/a-call-for-the-nix-team-to-present-a-unified-front-on-the-outcome-and-strategy-around-nix-flakes/54959/37 "2024-10-26T17:43:04Z")
> [@johnkyle](#):
>
> I’m wondering, what’s wrong with using niv for pinning and building with NixOS modules, aka the “Classic Nix” mode? I’m asking because I haven’t used niv for a real project yet, so I don’t know what sharp edges may be there. It seems perfect for filling this need without bringing along additional problems.
I’m actually using niv at work in our monorepo, but I don’t like that it’s a separate project, I have to keep the `sources.nix` file and it’s not really straightforward to actually use these niv-generated code files.
I’d move to flakes, but it’s slow and takes a lot of disk space (copying the entire repo checkout (~1GB) to the nix store every time I change a few line of code in a single package is simply unacceptable).
The way I see it, if flakes feature was just a new nix subcommand around something like [flake-compat](https://github.com/edolstra/flake-compat) it would already be enough to make niv and other such tools unnecessary.
---
### Author:  [@johnkyle](https://discourse.nixos.org/u/johnkyle)
#### Post date: [October 26, 2024, 5:59pm UTC](https://discourse.nixos.org/t/a-call-for-the-nix-team-to-present-a-unified-front-on-the-outcome-and-strategy-around-nix-flakes/54959/38 "2024-10-26T17:59:40Z")
My opinion is this exposes too much interface for it to be the normal, default way for new users. You have to think about hashes, when tooling can easily handle it for you.
I was going to write some stuff about the new CLI and pluggability, but I really don’t know NixOS internals well enough. I do know this much: the current situation is that you can enable `nix-command` without `flakes` and you get a bunch of useful stuff, as well as flake commands that don’t function.
---
### Author:  [@takeda](https://discourse.nixos.org/u/takeda)
#### Post date: [October 26, 2024, 6:06pm UTC](https://discourse.nixos.org/t/a-call-for-the-nix-team-to-present-a-unified-front-on-the-outcome-and-strategy-around-nix-flakes/54959/39 "2024-10-26T18:06:44Z")
As someone who is just an user of Nix and contributes from time to time. Could you stop bike shedding about this? If you have a better solution that we currently have, where’s the implementation? If you just want to rip it off, because you’re so pure and can’t just not use it, and has to be removed, why not create a new fork, maybe call it “FlakelessNix” so will attract everyone who despises flakes, and see who will use it?
I have been strong advocate for Nix at places I work to the point I was considered as a Nix-nut and I’m starting to think that they are right and I’ve been wasting my time in this. The constant bickering is drawing people away. Do you want to kill this project? Because this is the best way to do it.
---
### Author:  [@numinit](https://discourse.nixos.org/u/numinit)
#### Post date: [October 26, 2024, 6:25pm UTC](https://discourse.nixos.org/t/a-call-for-the-nix-team-to-present-a-unified-front-on-the-outcome-and-strategy-around-nix-flakes/54959/40 "2024-10-26T18:25:47Z")
Out of curiosity, what is the purpose of this kind of infighting? Is it to influence the not yet formed steering committee who will be making delegation decisions in a matter of weeks to hopefully resolve things like this?
This kind of thing creates unnecessary division and likely alienates people who are new to the project. Regardless of whether flakes are in stable Nix or behind a plugin, everyone seems to need to get their opinion in about where the ship needs to sail when the community has no one at the helm just yet.
tl;dr: everyone should just relax. We’ve been going through an entire community governance process to avoid this kind of thing, all anyone needed to do is wait a couple weeks.
---
### Author:  [@samrose](https://discourse.nixos.org/u/samrose)
#### Post date: [October 26, 2024, 6:29pm UTC](https://discourse.nixos.org/t/a-call-for-the-nix-team-to-present-a-unified-front-on-the-outcome-and-strategy-around-nix-flakes/54959/41 "2024-10-26T18:29:26Z")
> [@johnkyle](#):
>
> My opinion is this exposes too much interface for it to be the normal, default way for new users. You have to think about hashes, when tooling can easily handle it for you.
>
> I was going to write some stuff about the new CLI and pluggability, but I really don’t know NixOS internals well enough. I do know this much: the current situation is that you can enable `nix-command` without `flakes` and you get a bunch of useful stuff, as well as flake commands that don’t function.
Exposes too much for newer users is a fair assessment for how to improve the UX/DX that makes sense to me.
I’ve also have had some success just teaching people how to use nix without needing to change the way nix currently works 4 times now. It can be done. It does take some time and education. I’ve been either leading or a part of introduction of nix to larger groups of developers in addition to directly using it.
---
### Author:  [@srd424](https://discourse.nixos.org/u/srd424)
#### Post date: [October 26, 2024, 7:11pm UTC](https://discourse.nixos.org/t/a-call-for-the-nix-team-to-present-a-unified-front-on-the-outcome-and-strategy-around-nix-flakes/54959/42 "2024-10-26T19:11:57Z")
> [@numinit](#):
>
> tl;dr: everyone should just relax. We’ve been going through an entire community governance process to avoid this kind of thing, all anyone needed to do is wait a couple weeks.
I’m guessing what’s worrying a lot of people is the feeling Det Sys is trying to push the issue towards a close, given the announcements, blog posts and commentary over the last week or so. I don’t think this discussion would have blown up now if that hadn’t happened.
[Previous page](https://discourse.nixos.org/t/a-call-for-the-nix-team-to-present-a-unified-front-on-the-outcome-and-strategy-around-nix-flakes/54959.md?page=1)
[Next page](https://discourse.nixos.org/t/a-call-for-the-nix-team-to-present-a-unified-front-on-the-outcome-and-strategy-around-nix-flakes/54959.md?page=3)