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

Links
7

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?

21 Likes
8

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
9

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
10

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

11

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?

12

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.

17 Likes
13

“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?

7 Likes
14

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.

24 Likes
15

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
17

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 :).

3 Likes
19

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

6 Likes
20

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
21

If he did not we would not have that debate.

22

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.

13 Likes
23

Evidence from GitHub strongly suggests that the Nix community is moving in the direction of flakes and the unified CLI en masse

Please don’t suggest that the number of people using something is in any way related to its quality. We’ve had lots of propaganda surrounding flakes, much like this very article; that’s why it’s being adopted so heavily.

And I hear from more recent Nix adopters over and over again that flakes were crucial to their learning journey.

And I, as someone who spends hours every week aiding people in chat rooms and forums, have seen massive amounts of confusion caused by flakes.

I believe that flakes are stable, and I’m not alone.

They’re “stable” because no one has bothered to make the breaking changes necessary to fix the many grievances with them.

31 Likes
24

Effectively he does have ability to veto a specific change, from what I have seen.

Popularity is effectively at odds with quality, unless maybe you can sell people on criticality of integrity at Postgres level. Flakes are a regression on design quality from previous state of Nix.

And when you market Flakes «for adoption» you end up with superficial incantations not attempts to understand a thing throughout and use based on that understanding — avoiding the risk that anything will get more consistent over time.

7 Likes
25

No, Eelco doesn’t have that authority

That might be the case today, but let’s not forget that this was clearly not the case when flakes were designed, initially merged into master, introduced everywhere despite an ongoing (and then closed) RFC.

I want to address three common criticisms of flakes.

No mention of lazy trees? oO
I think there was pretty much a consensus that this was the main issue to be addressed before dropping the experimental flag. Because flakes are absolutely unusable in large repos (I tried nix build .#hello on a dirty repo - i.e. a normal situation when working on nixpkgs and I decided that I’ll never do that again. Also the reason why I’d never sneak a flake.nix into a monorepo).

This PR completely exploded, started suffering from feature creep and… stalled. In fact it was pretty usable (to me at least, though I’m despite my criticism here a flake proponent and use them pretty heavily, so I considered that a good sign) at some point in winter last year until I got some weird breakage on each update and I had enough. Even worse, lazy-trees is the reason to revert other valid bugfixes that are… still bugs, e.g. Revert "Merge pull request #6621 from Kha/nested-follows" by edolstra · Pull Request #6983 · NixOS/nix · GitHub.

I mean, complaining about another NixCon without a clear way forward while there was a plan last year is… questionable to say the least.

But it has nothing to do with flakes and thus no bearing on stabilization.

Right now we depend on a single system attribute in several outputs (e.g. apps/packages) and the output discovery expands e.g. .#foo to .#packages.<builtins.currentSystem>.foo in nix build (briefly said).

This means that we have something that juggles around with a system field without taking cross-compilation into account at all while we skip the entire problem with the nix-* commands. Yes, that may or may not be pretty either, but with a design actively neglecting this, I don’t think it’ll be easier.

Also, this is nothing new: [WIP] Add 'perSystem' and 'systems' schema attributes by gytis-ivaskevicius · Pull Request #6773 · NixOS/nix · GitHub & Provide builtins.currentSystem as a input to flakes or make system a parameter · Issue #3843 · NixOS/nix · GitHub.

It’s a good read but I disagree with the conclusions. With evaluation caching and the functional nature of Nixpkgs, source explosion is generally mitigated using the follows mechanism built into flakes, which reduces the number of unique Nixpkgs instances involved in an evaluation.

I think the main point is the usage of import inputs.nixpkgs in each flake which will cause a massive amount of evaluated nixpkgs (and follows doesn’t work recursively, the fix was as mentioned rejected because it was too hard to mege against lazy-trees).

Also, evaluation-caching doesn’t help at all when working with the code because this cache (IIRC) only caches top-level drvs and not “intermediate” drvs in the dependency-tree, so everything will be re-evaluated in a dirty tree with fresh changes.

What you can do is e.g. builtins.foldl (nixpkgs: nixpkgs.extend) (nixpkgs.legacyPackages.${system}) [ overlay1 overlay2 overlay3 ] to use a single instantiated nixpkgs if follows is applied carefully everywhere (i.e. each flake passes a follows down to its subflakes properly). However you can’t configure nixpkgs that way (i.e. allowUnfreePredicate etc.).

prior to stabilization, as a new mechanism can increment the flake.lock version field.

At least I agree with that :wink:
See the difference to the other issues? This is something we can easily change without severe breaking changes.

I gotta say I’m rather surprised by this article. While I think we’re somewhat on the same page, i.e. I also think that flakes are a massive improvement for a lot of people (myself included - that’s why I’m using them since 2020 and have also contributed numerous fixes to it), I think that the core concerns about the current state are misrepresented in this article.

When I’ve read it first it seemed to me as if the the main message was that the only arguments from the community are shallow and only there because people dislike flakes in general. While I don’t think that this was the intention, that was my first impression. And I’m concerned that such prominent statements will only worsen the divide we’re already battling in the community.

36 Likes
26

I feel a strong urge to making breaking to changes to Flakes in order to clear up that

  1. “Experimental” means experimental

  2. Popularizing experimental features from the day they are created is an Uber-style “if we break the law long enough it will become legal” tactic, and it is not destined to work.

27 Likes
27

To be clear, that is not preferred outcome. My preferred outcome is:

  1. Flakes become a separate CLI
  2. Flakes get a separate website
  3. Flakes go to a separate repo

Ideally, I would not feel threatend by shoddy Flakes ruining the core of Nix’s good name; Ideally we would have separate brands for separated projects, and separate teams for separate projects. Then I don’t have to care what Flakes do, because there is little reputational exposure either way. People/companies that want to push Flakes for growth / “Worse is Better” reasons can do so all they want, and I don’t have to pay any attention to it.

Layering and multiple brands is the only way we’re going to keep this community bursting at the seams together.

20 Likes
28

I am heavy Flakes user, but I very much like the idea of Flakes separation.

10 Likes