Nix team member suggests removing flakes; data suggest it isn't a good idea, please remove the experimental flag instead

[autra]

@Birdee

Thats why I say, nix is not complete without flakes.

Yes that’s what I meant too. And for this reason I also agree that we should either make them stable (with maybe breaking changes before) or find something else. The status quo is indeed harmful now.

[7c6f434c]

@VanCoding

if the NixOS Org is even able to make decisions.

There has always been … limitations to the ability to make decisions.

However.

We do have a decision process now, RFC process, it just does not always converge.

Flakes were put through it and withdrawn, because people pushing Flakes did not want to immediately fix the numerouts issues brought up in the feedback.

Then later a plan to stabilise new UI, eventually making decisions on changes (or not) to Flakes, fixing the broken layering in the logic, and providing access to separate concerns, has been accepted as an RFC.

The current old-stable CLI is more logically consistent once you learn it (so: better) than the new one, and Nix team is actively fixing that from the new CLI side.

So if we consider quality, and the existing decision processes, stabilising Flakes as of now is making things worse on both counts.

The interest to fix the Flake brokenness is so that there is no atttempt to use them in Nixpkgs before the consistency is achieved.

[fredcamaral]

This post was flagged by the community and is temporarily hidden.

[samrose]

This one might be a possibility too https://cloud.google.com/blog/topics/public-datasets/github-on-bigquery-analyze-all-the-open-source-code

[samrose]

@7c6f434c

Then later a plan to stabilise new UI, eventually making decisions on changes (or not) to Flakes, fixing the broken layering in the logic, and providing access to separate concerns, has been accepted as an RFC.

Is this the RFC you refer to? [RFC 0136] A plan to stabilize the new CLI and Flakes incrementally by Ericson2314 · Pull Request #136 · NixOS/rfcs · GitHub

And maybe this is the tracking of it? CLI stabilization effort · Issue #7701 · NixOS/nix · GitHub

Maybe that’s a thread on it Stabilising the new `nix` command line interface ?

[polygon]

I hope while you dig into ideological battles that you don’t forget all the people already using Flakes to a sizable amount so they don’t find themselves in front of a huge back porting task or have their config become invalid all of a sudden. When I hear “yes, most people use it and like it, BUT IT’S STILL WRONG!!!” I get scared that these are the people in control.

I also don’t want to be forced to use “Determinate Nix, only $12.99 per user and month, don’t lose all the work you put into Flakes”.

[drakon]

No one is suggesting that using Flakes is ‘wrong’. The issue is that, despite their prevalence, they’re still officially an experimental feature and have been for years.

[Sandro]

Before flakes consuming any out of tree project was an absolute nightmare! Everyone implemented the interface how to load their code differently and injecting your pkgs into it was different for almost every project, sometimes being hardcoded to load certain channels. None of the other projects like niv or npins can fix that because they cannot enforce an interface.

IMO it would be very stupid to remove flakes at this point.

[waffle8946]

@Birdee

what is npins plus --pure

If normal nix plus purity was what you wanted you would have what you want already

Incorrect. There is no --pure flag for nix build and friends or nix-build and (most) friends.
What you may be thinking of is either

• --pure for nix-shell which only clears some envvars, and is only for development purposes obviously since nix-build doesn’t have this flag
• the pure-eval setting which only disables the currentSystem and currentTime builtins, and restricts network access (the latter of which the build env already does anyway…) - note that it still provides getEnv builtin and therefore presumably allows using channels (I didn’t test this, but <> syntax reads from NIX_PATH so this is not really good enough IMO.)

If pure eval already existed I would’ve used it and never complained about flakes.
Unfortunately all the good features of nix are being bundled with the worst possible implementation of a lockfile spec.

EDIT: also, the nix team themselves are aware that pure-eval without flakes is a desirable feature, see these from over a year ago: 2023-09-25 Nix team meeting minutes #89 and Practical pure eval for paths in non-Flake CLIs · Issue #9329 · NixOS/nix · GitHub

@Birdee

Flakes ARE a pure eval nix implementation.

Yes, you repeated what I said.

@Birdee

The general nix team and contributors all treat changes to flakes as if they were making changes to existing stable software because everyone uses them

So, it really doesnt make a ton of difference. They kinda already ARE part of stable, despite not technically being enabled by default.

All you need to do to pretend they are part of stable is add extra-experimental-features “nix-command flakes” or whatever to your build script in your custom installer ISO

and then you literally never need to interact with the fact that they are not technically stable yet.

You wrote a whole essay about how I should not worry that they are unstable… when my points had nothing to do with that
Flakes are slow and broken by design, I already laid out exactly the issues with them earlier in the reply that I linked.
I don’t care if they are “experimental” or not, I care that they suck. I want the nix team to break flakes and make them better.
Unfortunately Eelco and detsys are the ones who actively blocked any improvements and said “no we want flakes to be stable yesterday” and so we continue to see no progress.

[fredcamaral]

@waffle8946

Unfortunately Eelco and detsys are the ones who actively blocked any improvements and said “no we want flakes to be stable yesterday” and so we continue to see no progress.

I don’t see why the two “blocked” any evolution of flake. since it’s there, to anyone make the effort.

[waffle8946]

I don’t know why Eelco is blocking it either, and he doesn’t tend to respond on discourse so I doubt we’ll get much answers from him. And detsys is the company he owns, so same deal.

It has nothing to do with effort, though, he explicitly said (if you check the meeting minutes I posted above) that he does not want any breaking changes, while other team members took a more nuanced approach. So I am of the opinion based on cases like these that the nix team overall is more reasonable and Eelco is the one somehow blocking improvements. Of course the team themselves is welcome to correct me, as I wasn’t present for said meetings.

[fredcamaral]

@waffle8946

It has nothing to do with effort, though, he explicitly said (if you check the meeting minutes I posted above) that he does not want any breaking changes, while other team members took a more nuanced approach. So I am of the opinion based on cases like these that the nix team overall is more reasonable and Eelco is the one somehow blocking improvements. Of course the team themselves is welcome to correct me, as I wasn’t present for said meetings.

–flakesv2 solves the issue.

[waffle8946]

@fredcamaral

flakesv2

I’m only speaking of things that actually exist, as I find that more productive than discussing things that may exist 6 years in the future with some undefined scope.
But sure, we can look in 2030 to see if flakes are better at that time.
In the meantime, I am speaking about the status quo.

[7c6f434c]

@fredcamaral

–flakesv2 solves the issue.

Given the development precedent, not with the current approach to development.

@polygon

When I hear “yes, most people use it and like it, BUT IT’S STILL WRONG!!!” I get scared that these are the people in control.

Well, Flake-pushers Eelco included say exactly this to us about a ton of features that work in the current-old-stable interface. And I mean features they wanted to make impossible to implement on top of the abstractions provided by the new interface.

@polygon

I hope while you dig into ideological battles that you don’t forget all the people already using Flakes to a sizable amount so they don’t find themselves in front of a huge back porting task or have their config become invalid all of a sudden.

There are compat shims available anyway.

[drakon]

It ‘fixes’ an issue seemingly caused by Eelco’s conflict of interest with DetSys/FlakeHub, it doesn’t fix the fact that breaking changes can’t be made to an experimental feature purely because it could affect one persons financial interests.

[Ma27]

@Sandro

Before flakes consuming any out of tree project was an absolute nightmare

I must say, I think this hasn’t changed much.

Everyone handles the nixpkgs input somewhat differently. I still read the code of every single flake I’m importing (just as I read the Nix code in default.nix before) to make sure I don’t end up with yet another nixpkgs being instantiated making my eval even slower and never receiving updates.

[Sandro]

@Ma27

I must say, I think this hasn’t changed much.

I have an example here search.nuschtos.de/flake.nix at f87b9bbe1cbe1117115f4efce61549b398616f82 · NuschtOS/search.nuschtos.de · GitHub which I don’t think would have happened before flakes and loading the modules is pretty uniform. Most different things come from the fact that we don’t supply modulesPath or pkgs by default.

[jaen]

but it is soooo nice and simple to use! at least for any small scale project

And then it ingests all the multiple gigs of a monorepo you’re trying to use it with on every flake-related command. It’s been more than 2 years since the lazy-trees branch (Lazy trees by edolstra · Pull Request #6530 · NixOS/nix · GitHub) was opened and even longer since the issue was first brought up (Copy local flakes to the store lazily · Issue #3121 · NixOS/nix · GitHub) and yet it’s not done, while the people responsible for that PR push for flake stabilisation, instead of finishing this goddamn PR — yes, I know it’s probably not trivial, but then why not try to invest more resources into that instead of DetSys marketing? I wonder how they plan to market it to srs enterprise bznses, if flakes suck for the kind of repos such companies are likely to have? I use flakes and think they are serviceable enough for things like my NixOS configuration and whatnot, but each time I try to use it to support devens at my current $WORK it sucks. I don’t think it makes sense to stabilise something like that, without ironing those issues out first.

[waffle8946]

@Sandro

which I don’t think would have happened before flakes

Before flakes you would specify the file path instead of attrpath. Both require looking at the code or otherwise running commands to inspect it.
And as a good counterexample to consistency of flakes, the schema recognises HM configs but not HM modules (prior to nix 2.24) so we have proliferation of various HM module structures.

[nick_kadutskyi]

That was my problem but I resolved it by having the flake in a subdirectory and when I do nix develop or nix build I refer to the flake explicitly and use path: reference to avoid adding any files from git.