Experimental does not mean unstable: DetSys's perspective on Nix flakes

10 Likes

These are all Flakes deal-breakers for me:

  • As you mention, the dependency explosion problem. Except that I disagree that the follows mechanism is a good solution for that. It’s a hack and can cause various breakages. We need a version resolver. And no, I will not use your proprietary third-party project to hack around that.
  • Flakes doesn’t support passing arguments from the CLI. This is a clear downgrade from the stable commands. Eelco keeps saying that configurable derivations will address this, but it’s just a draft PR so far.
  • The system parameter having to be passed around is awful and a clear downgrade from stable Nix.
  • The flake.nix file not actually being a proper Nix file is a fundamental design flaw, it’s very inconsistent and leads to surprises, a clear downgrade from stable Nix.
  • Flake sources always being copied into the store for every single change is terrible and a clear downgrade from stable Nix, which supports arbitrary granularity about which files are copied to the store. The lazy trees PR, announced last Nixcon, is meant to address this, but it’s still not done and suffers from various bugs.
  • Evaluation purity and evaluation caching are tightly dependent on Flakes and its references. This should absolutely not be a requirement, Nix code should be able to use these features independently of Flakes. I started a draft for a proposal here (though I haven’t had the time to make it coherent).

Just overall, the core of Nix is tainted by Flake. Nix is such a good idea, and I want Nix to take over the world, but I would be deeply disappointed if this is what we end up with.

66 Likes

I want to be able to use flakes, but the performance of flakes in large repositories is abysmal, and it’s telling that this piece fails to mention this at all. This isn’t a “could it be better? sure.” level of inconvenience. I invite the author to stuff a few GB into a repo that sees heavy use and convince us that adding a dozen seconds to every single command is acceptable.

6 Likes

Obligatory link to @samueldr’s new very relevant blog post: Nix Flakes is an experiment that did too much at once…

11 Likes

It’s not like Nix flakes, imperfect as they are, prevent anyone from just not using them.

Some of their flaws can be fixed in backward compat. way. Some will require something like version = 2; key in the flake.nix to opt-in into a future better designs.

In the meantime flakes are awesome and onboarded tons of people into Nix.

5 Likes

The point of a stabilization process is precisely to avoid the need for that.

Yes, flakes are great, but there are glaring problems, and the last thing you want is to be stuck with those glaring problems because people don’t want to break backwards compatibility. If flakes are to be stabilized, things like the lazy trees issue need to be resolved first.

It’ll be awesome to onboard tons of new people, and flakes do make nix easier, but I’m not looking forward to explaining to that wave of people why every single git operation takes 10 minutes in their 50GB project directories.

And no, adoption figures don’t tape over that, that’s happening under the express understanding that flakes aren’t entirely ready. If flakes are considered stable, new users who don’t expect these kind of messy problems will quickly be driven away.

11 Likes

Experimental should mean unstable, there are such good opportunities to make breaking changes that would make flakes better. As it is, flakes are stalled without even being released…

I also think it’s a shame that the better CLI is locked behind flakes.
It would be nice to bring those improvements to everyone.

Flakes are not the only way to handle lockfiles, nor did they need to be.
As far as I’m concerned, flakes are just a terrible lockfile spec. I see your company wants to monopolise the actual benefits of lockfiles (version bounds) but this should’ve been part of flakes itself, if flakes are what people want.

You also forgot to mention in your article that, to date:

  • The only way to handle unfree packages in flakes is with an overlay
  • There’s no (pure) way to tell the nix3 CLI to go ahead and build on an unsupported system
  • Flake input url syntax is broken
  • There is still no concept of development-only inputs
  • Can’t reject flake config all at once, I have to manually reject each line of config, one by one…
  • The global registry exists and is enabled by default (although easily disabled, it encourages terrible code)

PS Isn’t Eelco part of DetSys? He’s collaborating with himself?

17 Likes

Sure, that’s true! DetSys has invested entire months of Eelco’s time into the lazy trees work, which should make major improvement there. Another improvement that doesn’t need to wait for experimental to be lifted.

A lot of deal breakers on flakes for people are reasons they don’t like them, but have not been dealbreakers for many thousands of people who now depend on them. It’s okay to not like them or to not use them, and also for them to have their experimental label removed to reflect the very real status: being extremely stable.

We shouldn’t break them, making them unstable.

1 Like

What’s the point? To wait forever for some perfect design and flawless implementation?

Backward incompatible versions are not an end of the world, as long as a smooth gradual upgrade path is maintained.

Case in point: Rust editions.

This one is fixable without breaking backward compatibility. And majority of project are not that large.

Popularity breeds quality, not the other way around. “Worse is better.” By onboarding users, you give organizations and people incentive to actually improve things in their own self-interest.

Waiting forever for a project to be “perfect” is counter-productive.

7 Likes

This onboarding has happened via flakes already, and those folks are pretty happy with their experience :).

I’ve always wondered what this sentiment means. Can you help me understand? Yes: Eelco is a cofounder of DetSys. Do you mean to say that Eelco could just up and remove the experimental label, like he’s the final authority on that?

When I started my nix journey (maybe 2y ago) I got the message that flakes were the future, so I kind of stuck my head in the sand about everything else and tried to embrace a flakes-only mineset. I didn’t realize that I had made what appears to be a political choice.

So now it’s weird, because insofar as I’m capable of using nix, it’s through flakes (and I like them quite a lot). But I can tell from how people approach this issue that had I been around for longer, I’d be on the other side of this: If there’s ever an opportunity to gather together and vilify a company, I’m the first one to reach for the pitchfork.

For what I want to use it for, none of flakes’ limitations matter (well, except maybe this one). But if it’s gonna be this rift, well now I have to worry that I’m leading people into murky waters by pointing them at a flake that I wrote from them and saying “use this”.

Is there something I can be doing to help prevent this rift from becoming a forever thing? Because I really like it if it could not be a forever thing.

13 Likes

“We can declare flakes as stable today and find ways to address source explosion under the banner of flakes as a stable feature of Nix.”

I think this is the most straight forward way to move things forward instead of further dividing the community on this topic. I cannot remember how many times I’ve tried to explain to people(mainly new to nixos people) why flake is still “experimental” but they should really just give it a go. Then there’s just waves of discussion of ‘to flake or not to flake’ for reasons all similar to people posted here and before. I’m really tired of this.

Sure there are many half baked or unsolved features with flake, but can we just declare them stable now and move on? Is there a way community can vote on this topic?

6 Likes

To me it all comes down to philosophy.

You either do thing in a “best we can with what we have” or for a pleasure of doing things well for its own sake. Philosophy of Haskell aka “Avoid Success At All Costs” vs philosophy of Rust. Or in other words: Makers vs poets.

When Rust decided to stabilize, it took about a year, with a clear deadline, where project was scrambling getting as much as possible to future proof it and call it stable, with an escape hatch of editions system working.

Haskell has like thousands software years and people are still writing blogs about leaving it in part because of breaking changes all the time.

The need for Nix in the industry is so strong, that it caused a huge influx of more and more members of the “makers” tribe, that just want to use Nix productively. They don’t expect perfection. They routinely deal with software waaaaay, waaay less well designed than flakes. It’s a tough bug-eats-bug world out there.

Flakes are just something that one can onboard users to and use practically. “flakes are like Cargo.toml or package.json but for everything”. It just makes sense. And they work. The dev shells themselves with locked dependencies are a huge upgrade, because how easy they make onboarding people to non-trivial projects. I can’t imagine not using them (or something like it) anymore.

From all the pointed out flaws only system parameter strikes me as an obvious, backward incompatibility to either accept or break now. I find it mildly annoying. Everything else seems like “we’re not ready, it’s not perfect yet”.

There will be a need for “flakes 2.0” no matter what. Either make the most important future-proofing now to make “flakes 1.0” as good as possible and accept that better designs will either be clumsily fit into being backward compatible, or have to wait for 2.0, or the flood of motivated “makers” are just going to more or less explicitly do it for you. Because at this point there’s already more projects and more steam behind flake-users and the fact that flakes are experimental is becoming more and more irrelevant, with people advertising and using unofficial installers that enable them by default, etc.

20 Likes

Is this incorrect? Seems like many of the issue I raised above are unfixed because Eelco personally vetoed them.

Also I missed an opportunity to address your core point: people depend on flakes, and some new people had great experiences with flakes, so flakes should never be broken.

I will say this: I dislike the framing that detractors are all grumpy longtime members of the community, so I will mention a couple of things:

  • The biggest detractors of flakes are the ones that use it the most (if we didn’t use it at all, we would never know its issues firsthand)
  • We’re also the most invested in seeing flakes improve (after getting invested in flakes, it’s not like I want to actually switch again if I can help it)
  • my data point - I am new to nix (3 months into the learning journey), and last month I couldn’t figure out how to install my own (unfree) software that I developed on my own machine (not part of nixpkgs), using unfree predicate, without lying to nix about the license. (I couldn’t figure out the overlays output of flakes, tbh.) I just gave up and removed meta.licenses from my repo. (Sure, now I can say “I know better”, but it was a frustration at the time. And forcing an overlay feeds back into the source explosion issue.)

It’s also telling that even a new user like me can bump into so many of the flakes issues in only a few weeks’ time…

The way I see it there is no “rift” in the sense of people wanting to scrap flakes, simply those who want to see flakes be better, and those who think it’s good enough bc their own use cases are satisfied.

The only thing I wonder is, if flakes are marked stable, will the issues get fixed, or will flakes suck forever? (They are still better than channels even now, but flakes vs. channels is a false dichotomy.)

11 Likes

No, Eelco doesn’t have that authority. The Nix team and the NixOS Foundation are a collaborative team of people of shared responsibility and authority. Eelco doesn’t hold that key. I’m quite sure if he did, it would be done by now :).

2 Likes

By the way, folks: for individual issues that you feel may or should block removing the experimental label, please consider opening an issue and referencing the flake milestone here. Ref: Start a Flakes milestone list · Issue #8870 · NixOS/nix · GitHub

5 Likes

I mean… Yes? He is the reason we got the experimental flag and this whole feature plus new cli all at once?

One of the things that has been problematic with flakes is the constant deflection of problems we encounter as “not important” by the main implementer while at the same time keeping it in experimental.

If you advocate for it so much and are so convinced this is great, then go for it man. If you do not, then sit down and actually learn from the experiment. Right now it feels more like “seagull management”.

And i know this was not the goal. If there is one thing I have no doubt about, it is that you all at DetSys believe this will be good for the world.

But this weird “it is so good for everyone it should be merged” while at the same time saying “yeah we need massive multi year work before it can be non experimental” and also telling everyone they should use it anyway…

It sends pretty mixed signals isn’t it?

14 Likes

If he did not we would not have that debate.

First off, I’m preemptively jet lagged on a plane to NixCon at the moment, sorry if this isn’t coherent or some points are covered by the article. I promise I read it a few hours ago.

I think the situation is a little bit more nuanced than “stable = hasn’t broken frequently” and “should we ship or wait for perfect?”.

I also think this discussion is a bit moot given that we have an accepted RFC about a path to stabilization. Presumably flakes would be marked “stable” at the end of that process, no?

Stability

On the first point, are flakes “stable in practice” because:

  • The fundamental design is good and we’re working on improvements around the edges?
  • We’ve been deadlocked on figuring out how to move forward?
  • There are fundamental Nix features that must be implemented before we can make user-facing changes?

These are all very different situations that present the same way to users: “I can keep doing what I’m doing and nothing breaks”. I would argue that only the first case is a good candidate for stabilization.

Another question: what do we mean when we tell a user a feature is “stable”? I would argue that it means that a feature is reliable in the sense that both the code works without the need for constant maintenance and it’s valid to build a mental model around the idea. I think given all of the drawbacks mentioned so far, the solutions could require a user to substantially change their mental model of what a flake is/does after all these issues are sorted out.

Ship it vs. keep it in the lab

Obviously there’s a spectrum here. With everyone from hobbyists to corporations depending on Nix it’s not a good idea to “move fast and break things.” It’s also unproductive to wait until something is absolutely perfect before releasing it.

I would argue that fundamental flaws that need fixing weigh heavily in favor of keeping a project in the lab. Incomplete features are fine as long as they can be completed later without requiring “too much” extra work to add the missing functionality (ie you don’t have to change major parts of the system to fix the problem you created for yourself).

I also think that a large number of issues weighs heavily towards keeping the project in the lab.

12 Likes