4 ms·

How long are we going to sit on our hands and pretend flakes aren't the only way forward? Am I just missing something?

by thomastjeffery 4y ago

melvyn2 4y ago
I have not used flakes at all for my NixOS server. To put it one way, why should I care?
- pmarreck 4y ago
  (speaking as someone who hasn't actually fully converted over to flakes yet) Because it actually fulfills the original promise of Nix: Forever-reproducible builds. Anyone who's ever dealt with a lockfile across any stack that supports that idea in dependency definition, knows how this works and what it's good for.
  - lijogdfljk 4y ago
    Couldn't agree more. I love Nix (well, i have nits with the lang/UX), but Flakes is essential imo. Using Nix without Flakes is going through 99% of the trouble for concrete, reproducible builds but then dropping the last 1%. I had my non-Flake builds break like it was a mutable operating system. I just don't get why Flakes aren't the standard.
- rgoulter 4y ago
  The UX is much nicer with flakes. Flakes provide a consistent entry-point to a set of Nix files (rather than just a hoping that Nix files conform to some convention). Nix flakes also let you get by with even less worry about the system state: e.g. you don't need to add channels or put your code in your user's overlays directory. You can just use the path/URI to a flake, and nix will take care of downloading all the inputs appropriately.
chriswarbo 4y ago
I've not bothered with flakes (yet?); mostly because I don't quite understand/appreciate what they're for/add. They're apparently better than using channels, and env vars like NIX_PATH; but I don't bother with those either. I just use `fetchgit`/`fetchFromGitHub` with specific commit IDs, and that seems mostly reproducible. I've got Nix repos dating back about 8 years, and the only reason some commits can't be reproduced is due to link rot (mostly GitHub repos being deleted in protest at Microsoft purchasing it). I don't think flakes solve that? (Seems more suitable for something like IPFS)
- rgoulter 4y ago
  One thing flakes enable is "easily run some other source". e.g. to run the latest build of Nix from the GitHub repository NixOS/nix on the master branch, it's: nix run github:NixOS/nix/master Or (say) the Helix editor has a flake.nix; so a similar command would work for that. -- Being able to use nix code without having to fetch the source first is pretty neat. A less contrived example of where this is useful is with Home Manager. Setting up Home-Manager without flakes requires adding a channel (or requires using a NixOS module, which only works on NixOS). -- Whereas with flakes, you can declare Home Manager as an input, so that applying the Home Manager configuration can be done with less effort. Flakes are like "nix's nix". With nix, you benefit from putting in effort to declare the inputs of some package, and how its outputs are constructed. With nix flakes, you declare where the Nix code you're using comes from.
  - chriswarbo 4y ago
    > Setting up Home-Manager without flakes requires adding a channel (or requires using a NixOS module, which only works on NixOS). From the home manager documentation ( https://nix-community.github.io/home-manager/index.html#sec-install-standalone https://nix-community.github.io/home-manager/index.html#sec-... ): > If instead of using channels you want to run Home Manager from a Git checkout of the repository then you can use the programs.home-manager.path option to specify the absolute path to the repository.
    - rgoulter 4y ago
      Neat, though I hope I helped your curiosity regarding why people find flakes useful. With home-manager, you can declare a flake configuration where home-manager is an input; and then applying the configuration is pretty hands-off since Nix will fetch the appropriate revisions of the inputs. I think that using flakes is more convenient than the alternatives. (Having to add a channel; or, as you point out, cloning the repository in a consistent path on each system you use & then running that).
      - pxc 4y ago
dd_ 4y ago
Well they are - but there are a couple of things blocking it from becoming the default. I think the main thing is this PR: https://github.com/NixOS/nix/pull/6530 https://github.com/NixOS/nix/pull/6530 - Eelco Dolstra gave a talk on this recently as well if you wanna know more: https://www.youtube.com/watch?v=JE-vLFMTXxM https://www.youtube.com/watch?v=JE-vLFMTXxM Another thing that comes to mind is the ability to parametrize flakes so that they can be configured from the CLI: https://github.com/NixOS/nix/pull/6583 https://github.com/NixOS/nix/pull/6583
- pxc 4y ago
  I check on that lazy trees PR like twice a week, lol. It's my most anticipated Nix PR for some time now. I imagine I'm not the only one!

How long are we going to sit on our hands and pretend flakes aren't the only way forward? Am I just missing something?

melvyn2 4y ago

I have not used flakes at all for my NixOS server. To put it one way, why should I care?

pmarreck 4y ago
(speaking as someone who hasn't actually fully converted over to flakes yet) Because it actually fulfills the original promise of Nix: Forever-reproducible builds. Anyone who's ever dealt with a lockfile across any stack that supports that idea in dependency definition, knows how this works and what it's good for.
- lijogdfljk 4y ago
  Couldn't agree more. I love Nix (well, i have nits with the lang/UX), but Flakes is essential imo. Using Nix without Flakes is going through 99% of the trouble for concrete, reproducible builds but then dropping the last 1%. I had my non-Flake builds break like it was a mutable operating system. I just don't get why Flakes aren't the standard.
rgoulter 4y ago
The UX is much nicer with flakes. Flakes provide a consistent entry-point to a set of Nix files (rather than just a hoping that Nix files conform to some convention). Nix flakes also let you get by with even less worry about the system state: e.g. you don't need to add channels or put your code in your user's overlays directory. You can just use the path/URI to a flake, and nix will take care of downloading all the inputs appropriately.

chriswarbo 4y ago

I've not bothered with flakes (yet?); mostly because I don't quite understand/appreciate what they're for/add. They're apparently better than using channels, and env vars like NIX_PATH; but I don't bother with those either. I just use `fetchgit`/`fetchFromGitHub` with specific commit IDs, and that seems mostly reproducible. I've got Nix repos dating back about 8 years, and the only reason some commits can't be reproduced is due to link rot (mostly GitHub repos being deleted in protest at Microsoft purchasing it). I don't think flakes solve that? (Seems more suitable for something like IPFS)

rgoulter 4y ago
One thing flakes enable is "easily run some other source". e.g. to run the latest build of Nix from the GitHub repository NixOS/nix on the master branch, it's: nix run github:NixOS/nix/master Or (say) the Helix editor has a flake.nix; so a similar command would work for that. -- Being able to use nix code without having to fetch the source first is pretty neat. A less contrived example of where this is useful is with Home Manager. Setting up Home-Manager without flakes requires adding a channel (or requires using a NixOS module, which only works on NixOS). -- Whereas with flakes, you can declare Home Manager as an input, so that applying the Home Manager configuration can be done with less effort. Flakes are like "nix's nix". With nix, you benefit from putting in effort to declare the inputs of some package, and how its outputs are constructed. With nix flakes, you declare where the Nix code you're using comes from.
- chriswarbo 4y ago
  > Setting up Home-Manager without flakes requires adding a channel (or requires using a NixOS module, which only works on NixOS). From the home manager documentation ( https://nix-community.github.io/home-manager/index.html#sec-install-standalone https://nix-community.github.io/home-manager/index.html#sec-... ): > If instead of using channels you want to run Home Manager from a Git checkout of the repository then you can use the programs.home-manager.path option to specify the absolute path to the repository.
  - rgoulter 4y ago
    Neat, though I hope I helped your curiosity regarding why people find flakes useful. With home-manager, you can declare a flake configuration where home-manager is an input; and then applying the configuration is pretty hands-off since Nix will fetch the appropriate revisions of the inputs. I think that using flakes is more convenient than the alternatives. (Having to add a channel; or, as you point out, cloning the repository in a consistent path on each system you use & then running that).
    - pxc 4y ago

dd_ 4y ago

Well they are - but there are a couple of things blocking it from becoming the default. I think the main thing is this PR: https://github.com/NixOS/nix/pull/6530 https://github.com/NixOS/nix/pull/6530 - Eelco Dolstra gave a talk on this recently as well if you wanna know more: https://www.youtube.com/watch?v=JE-vLFMTXxM https://www.youtube.com/watch?v=JE-vLFMTXxM Another thing that comes to mind is the ability to parametrize flakes so that they can be configured from the CLI: https://github.com/NixOS/nix/pull/6583 https://github.com/NixOS/nix/pull/6583

pxc 4y ago
I check on that lazy trees PR like twice a week, lol. It's my most anticipated Nix PR for some time now. I imagine I'm not the only one!