Enable flakes by default?

General
1

Should we enable flakes by default on our fork?

2 Likes
2

Not yet, we will want to make larger changes like that in Phase 3 of the roadmap, Organization:

4 Likes
3

Just one question: if we’re defaulting to flakes in Phase 3, should we retain legacyPackages? This comment highlights that using packages slows down operations like nix flake show nixpkgs. There’s also the argument that the flat structure of packages doesn’t align with the nature of nixpkgs. However, this issue could potentially be mitigated if we are splitting the packages into their own repositories, such as python haskell linux.

So, should we consider renaming it at least? Even their comment basically says, don’t be misled by the bad name; legacy literally doesn’t relate to legacy at all.

2 Likes
4

We will be resolving this issue as we move forward, but I think I am leaning towards ditching legacyPackages. It would make the whole experience more convenient.

5 Likes
5

what’s the point of not using legacyPackages? the name is misleading (it should have been called nestedPackages or something), but what about it is “inconvenient”?

2 Likes
6

Is the direction viz. flakes already determined, or is it TBD until Phase 3?

My cards on the table: I think removing flakes is probably a good idea.

7

Pretty much everything is up for discussion.

I could not disagree more. Removing flakes would make life incredibly unusable for people like myself who could not run all my systems in the way that I do. And flakes are much more declarative then channels since they have a lockfile meaning they are always pinned to an exact version.

8 Likes
8

I’m all for stabilizing flakes, but I want to make sure we have a path forward for “flakes 2”

“Flakes 2” is what I’ll call the next iteration of improving flakes that would need incompatible changes.

Has there been any discussion on forward compatibility in the nix spaces about that?

Could it be as simple as having version = 1; at the top level, next to inputs and outputs? I guess when flakes 2 work starts, if version is missing, it could be implied as 1, but then mandatory for v2 support

5 Likes
9

So, as a complete beginner to the flakes vs no-flakes discussion, why do people not like flakes?

I’m not trying to start a flamewar here, I’m just seeking to understand from the pov of a nix newbie who very much enjoys using flakes.

1 Like
10

I like flakes too. But there are some shortcomings as they exist today. (Which is fine IMO, I think the more important concern is the ability to improve those over time, like my simple version idea).

Read the “Flakes aren’t real and cannot hurt you” post on the jade.fyi blog for a good entry point to the discussion on it

2 Likes
11

Oh, interesting.
I’ll check that blog post out. Thanks!

12

Have you looked into sanix, pins, or niv? I think there is a way to get the “good” of flakes and not use channels without taking on the problematic aspects of the flakes implementation.

13

I have seen those but none of them are a great way to get nix working on darwin. Flakes is a must have for darwin if I’m being honest.

2 Likes
14

That was a really good post actually. On which note it might be worth removing the builtin fetchers.

2 Likes
15

There are a few factors:

  1. Some people are not happy with the governance side of how flakes were integrated as experimental.
  2. Some people do not like what they see as the tight relationship of Determinate Systems and flakes
  3. Some people are frustrated that flakes are still not stable after all these years.
  4. Some people think that flakes / non-flakes splits the community and documentation in an annoying way.
  5. Some people think that flakes have impeded the improvement of, e.g., the base Nix CLI.
  6. Some people object to the fact that flakes are not really written in Nix language.
  7. Some people are frustrated that flakes have a hard git dependency.
  8. Some people are frustrated that flakes copy everything into the store, and other similar design flaws.

For example on point 8, flakes can’t use the fileset feature that makes extracting only the code bits of a repo easy.

1 Like
16

This is kinda where I’m at as well. Flakes are a sound idea IMO, but the current state is definitely a bit how-ya-doin in a few spots (legacyPackages is a weird name for that, flakes are actually a weird subset of Nix, everything in the flake has a hard requirement on being in Git). It’s nothing unsolveable, and I think trying to tackle that would be a good idea at some point in the future.

17

I have a vague recollection of a upstream tracking issue working on removing the decency on git for flakes.

18

i’m pretty sure i’ve used flakes that are not part of a git repo, i’m not sure what you’re talking about here. do you mean the fact that if .git exists, all files not in the index will be ignored?

19

removing builtin fetchers would break basically every single non-flake system. i’m fairly sure nixpkgs uses builtin fetchers to bootstrap (nixpkgs fetchers depend on curl, but obviously there’s no way to get the curl binary if you can’t download anything)

20

For fetching things that are needed to build but not needed to evaluate, flake inputs suffer from a poorly documented limitation of builtin fetchers, which is the reason they are banned in nixpkgs (in addition to restrict-eval making them not work), is that they block further evaluation while fetching. The alternative to this is to use a fixed-output derivation that performs the fetching at build time, such as is done with pkgs.fetchFromGitHub , pkgs.fetchurl and so on.

- Flakes aren't real and cannot hurt you: a guide to using Nix flakes the non-flake way - jade's www site