This post was flagged by the community and is temporarily hidden.
4 Likes
Previous experience tells me that it’s really easy to fall into “automatically assume the worst everywhere” and repairing that is just hard and takes time. 
3 Likes
This post was flagged by the community and is temporarily hidden.
7 Likes
This post was flagged by the community and is temporarily hidden.
This post was flagged by the community and is temporarily hidden.
1 Like
This post was flagged by the community and is temporarily hidden.
2 Likes
This post was flagged by the community and is temporarily hidden.
This post was flagged by the community and is temporarily hidden.
5 Likes
Can we not mix two separate dramas in one topic, please? xD
For the on-topic drama, there’s this plan here rfcs/rfcs/0136-stabilize-incrementally.md at f557e0736e3110f49df16de76ca2185ef43e116f · NixOS/rfcs · GitHub that @tomberek mentioned and probably helping with is the best way forward, but I’m not entirely sure what’s the best place to track progress and what needs to be done. I see CLI stabilization effort · Issue #7701 · NixOS/nix · GitHub, but that’s just the CLI part, there’s probably more? Looking at groups with “stabilisation” in their title here (Nix team · GitHub) makes it seem as we’re almost done, but I guess we wouldn’t have this drama if it were so. I think a clear overview of this would be helpful, both to see where we’re currently at and that people like @camtauxe can maybe nibble at some tasks to help push it forward?
16 Likes
I’m not entirely sure what’s the best place to track progress and what needs to be done
About a year ago Infinisil gave a good overview of problems with flakes as of back then: Experimental does not mean unstable: DetSys's perspective on Nix flakes - #2 by Infinisil
I have no idea which of these issues have been tackled in the last year.
Earlier in this thread @nrdxp also made a nice point - in a post that sadly got flagged due to who knows why - namely that flakes just lack any internal structure and that what is needed is something akin to a module system of structuring your Nix code. Which they don’t deliver.
I have no idea if there is a way to track any work on flakes short of being a Nix team member or going to their meetings? So far only fricklerhandwerk and Tomberek have said something
They didn’t sound overly encouraging if you ask me.
8 Likes
Yes, getting back to the original point, it is extremely ironic that @grahamc posts this here and now, as he is probably the one singular person with the most ability to push flakes in a direction. And it seems this is the direction he is pushing. Don’t forget, he’s (not so) passively implied that they’d fork and go private if necessary.
huh? Where did I do that? Why would we do that / why would it be necessary? Even if we wanted to (which we don’t) how could we do that, since Nix is LGPL?
3 Likes
Twitter. Something along the lines of “it’d be a shame if those MIL companies just went private” – but twitter is a complete walled garden now, so…
You tell me.
You’ve effectively done it with Determinate Nix, no?
If you can find where I implied we’d somehow(?) take Nix private, I’d be grateful, thank you!
No. All of our patches to Nix are completely public and available. Under the terms of the LGPL, determinate-nixd could link against Nix, but sources for modifications to Nix must be available. Additionally, determinate-nixd executes the Nix daemon and command line tools. See: Determinate documentation
4 Likes
The meta commentary here is that the Nix community–the loud folks that bother to post anyways–seems would rather starve to death while making the perfect sandwich than settle for something to keep them going until they can get better ingredients.
You’re not the only one with this take but let me take this as an example.
This makes me sad to read. It’s definitely not giving “us” the benefit of the doubt, it’s assuming the worst. There’s no curiosity about what experiences might lead us to believe this. We’re just complaining for the sake of it, like anyone opposing flakes is some entitled, unrealistic prima donna, untethered from reality. Unrealistic “academics” who don’t understand that reality is about solving problems.
It’s sad because it’s ironic how far this is from the actual situation. In reality, I try and sell people on Nix regularly. I advocate for it, and flakes have very real problems that make them hard to use, hard to understand, hard to adopt, hard to explain.
Then, even if they take my word for it, beware anyone who uses a monorepo. The “multiple flakes per repo” bug and lack of lazy trees have on multiple occasions made people abandon the entire experiment. That’s not some academic opinion I hold in my ivory tower, me the only person who bothers to comment; that’s what I see really happen out in the wild with people who don’t even know that this forum exists. I know we’re close to solving that (we always are), and I’ll hear you out on it, but clearly I’m in the trenches when I object to flakes.
There’s a couple of killer features (fetchTree and its integration with the CLI; the ability to just run anything from a repo without even downloading never mind installing is close to magic), but the warts are real, and they look hard to solve because Flakes are doing too much. They’re cutting at the wrong abstraction layer.
And this is my second objection to the “let’s just adopt flakes now and fix the bugs as we encounter them” line: that doesn’t account for the scenario where flakes are a dead end, because the abstraction is wrong. Maybe these problems need solving separately. Can we pick this experiment apart and adopt independent bits?
When comments are directed at people rather than their ideas like that, it becomes frustrating. I know it’s not personal, but to read my objections (borne from actual observations in real life) brushed off as academic whinging, as unrealistic hallucinations, as if I’m just in it for myself, is disappointing. I wanted flakes to succeed.
Maybe that’s what’s missing from this? Does that help clarify my position? I actually want flakes to succeed! I even use them myself. I’d much prefer it if I thought they were good to go. I don’t want to spend my evening on discourse.nixos.org fighting with other people who are interested in improving Nix. We’re on the same team. I think Nix is good, I want flakes to be good, I want Nix to be appealing to the masses. In fact I think Nix for Windows is the most important Nix project happening at the moment, for the amount of people to whom it will make Nix available. And lo: every flake is {aarch64,x86_64}-{linux,darwin}, at best. Yet another point of friction for adoption. I dutifully use systems.url = "systems" in all my flakes, like a clown, because oh boy, any day now, our windows friends are coming and they’ll want to be able to use my flake by overriding the systems input to add support for windows. 
I’m sure there’s already a work-around for that, too. But why are we committing to stabilizing something we know is broken? Wasn’t that the point of making it experimental in the first place?
I actually think it’s flakes that make Nix harder to adopt. Even something like “nixpkgs.legacyPackages” is half-way impossible to explain (and the justification would be funny if it weren’t so tragic). How are we going to sell windows users on this ecosystem if they’re so explicitly not on the list? That’s the biggest group of potential new Nix users out there, by far.
All this stuff is much easier to solve in a v1 than a v2.
What are your experiences like explaining flakes to others? Not just your own, but when you explain flakes to newcomers: what is that like? Do you find yourself saying “yeah I know–just accept it for now”?
Believe me: I want Nix to be good. Easy to use. Easy to adopt. But Flakes aren’t panning out that way, and I think they actively hinder us in developing something better.
And if your experience is different: great. Happy to hear it. But please stop acting like we’re not on the same team. Trust me if you don’t actually care about Nix you’re not spending a second on this damn forum. 
PS: I’m giving devenv a better look @domenkozar thank you for your work. Should’ve been more serious about that, sooner!
18 Likes
I mostly stopped interacting with the Nix community due to the behaviour of DetSys.
That said, I will be explicit.
There will be no decision from “the Nix Team” on Flakes unless Eelco himself take one. Eelco is from DetSys.
So @grahamc , if you indeed feel like flakes should be stabilised or that they should be in or out, I suggest you stop bullying members of the community doing hard work in public, and go talk to your coworker himself.
Flakes are his baby. His project. And he is tasked with most of the work that he assigned himself to, in order to stabilise it. They are his design.
I don’t care if they are good or bad, but I am tired of seeing the dissonance of the same entity being in control of the thing and also yelling at others for not controlling the thing.
That behaviour is why I am out.
8 Likes
He is essentially out of the governance project and once the foundation will elect the members will also be formally
1 Like
And? He is still the main technical lead on flakes. I do not think he has his commit bit or voice in the technical decision taken out
Being in the foundation leadership was never the problem for this…
2 Likes
This is the first time I hear about an effort to add Windows support.
Wouldn’t it make more sense to first get all the issues with the currently supported platforms ironed out?
To a naive outsider, this looks like it’s yet another distraction that adds complexity to a project that is almost collapsing under it’s technical debt.
What’s the rationale here?
1 Like