6 ms·

I've been smitten by NixOS ever since I first tried it 2 years ago. Its the first carefree experience I've had with my system. As a side note, this result inclu

I've been smitten by NixOS ever since I first tried it 2 years ago. Its the first carefree experience I've had with my system. As a side note, this result includes first tiny contributions of mine! That said, I really hope the community gets their stuff together on Flakes. They're designated as experimental and official document doesn't recommend them, but all the cool kids are already using them everywhere and it is fracturing the efforts and alienating newcomers.

_huayra_ 5y ago
I really can't believe they didn't finalize Flakes in this release. The difference between it and the "standard" way of doing things is night-and-day. these sort of "secret better ways of doing things" that are not the default really frustrate and drive away new users
- mikepurvis 5y ago
  As another learner, I'm pretty upset about this as well. Standard install gets you nix 2.3.12 (https://nixos.org/download.html https://nixos.org/download.html), but to get flakes, you have to be on nix-2.4pre20210503_6d2553a: https://nixos.wiki/wiki/Flakes#Non-NixOS https://nixos.wiki/wiki/Flakes#Non-NixOS (And yeah, obviously all the docs are non-flake too, which leads to confusion about flake.nix vs default.nix...)
- e3bc54b2 5y ago
  By the way things are, I doubt they'll be stable in next release either. There were some pretty fancy things in last year's NixCon so devs might just push on that. But the problem is, many many new shiny things are so comingles with flakes that they are now stuck in limbo, thanks to the one amazing feature that was showcased back in 2019 and then rotted away in implementation hell. Initial RFC was rushed, barely discussed (there are lots of comments, but very little progress, as is the way with flakes) and then simply merged as experimental akin to pushing mess under the carpet. Well the mess was useful, but now the carpet is uneven and the first timers can barely walk straight. I just want a conclusion on flakes, any conclusion would be better than this stupid silent march.
  - _huayra_ 5y ago
    I wonder if there are any contentious design decisions left in flakes. I've still new to Nix, but it seems pretty solid (the only thing I've seen is that `nix flake info` is now `nix flake metadata` or something minor). The only missing thing I've seen is how to load a repl with flake contents easily, but I usually do: nix-repl> builtins.getFlake (toString ./.) when I'm in the flake directory. It would be nice to have `nix flake repl` as well.
- tazjin 5y ago
  The problem with this is that flakes are currently an experiment, and one which many people in the community think has flaws that need another iteration. Making it stable now locks Nix into the current flakes model forever - it's too early for that.
  - e3bc54b2 5y ago
    Agree. I think the core of the problem was that we didn't get a discussion before implementation. We got an implementation and then were given chance to discuss upon. So when the discussion pointed out flaws, since so much work was already put in, it was decided to push as experimental instead of starting from square 1. But now that implementation was available for everyone with simple flag change (a strength of Nix, if I might say), adventurers started using them. And since these adventurers have outsized impact in terms of mind share projection, the community looks divided and confuses the hell out of newcomers. I know I struggled with this because when I started learning 'The Nix Way™', flakes were the hotness and everywhere, but the documentation sucked, but still looked like they were the future so I had to wade my through anyway.
  - _huayra_ 5y ago
    What part of flakes might be up for discussion? The only quirky part I see is how one has to "rewire" inputs of your own inputs (e.g. nixpkgs from an input to one's current flake) via that `follows` directive, but overall it's been rather pleasant compared to channels!
Ericson2314 5y ago
I'm glad we didn't yet stabilize because I am skeptical of a number of aspects to Nix. I suspect it's unduly popular because pure eval mode is a food idea, but there is little way to use it outside of flakes.
- Ericson2314 5y ago
  s/to nix/of flakes/, to be clear
  - pxc 5y ago
    what do you think of the strategy of stabilizing just the input schema for Nix flakes, which is all that's required for pure evaluation, then stabilizing each component of the output schema separately as those components are called for by specific features of the Nix/NixOS CLI?
    - Ericson2314 5y ago
      That's a neat idea and improvement for sure. I'm pretty pessimistic about the outcome here, and perhaps what you said is a most realistic turn. There is a larger issue that still irks me: all this stuff is based off Cargo/Cabal/etc., but I think that's fundamentally the wrong model for our purposes. Historically every C package is a snowflake and we do need to package them individually. But as language-based ecosystems take off, we increasingly can auto generate everything we need, and our Nix code is not the bricks but the mortar. More concretely, the things I do with nix-thunk / Niv today don't really correspond to package boundaries that much, and if they do those repos might not contain any Nix code because I callCabal2nix them. callPackage-style "I am a function of my dependencies" is right, but when those dependency derivations don't align 1-1 with my nix-thunk / niv usage or need extra preprocessing à la cabal2nix, the fundamental concept of flakes breaks down.
      - pxc 5y ago
        I agree with the general orientation in favor of the monorepo and transforming package definitions from repos that don't know/care about Nix, then aggregating them. I think the vision where we use Nix mostly by way of Nix code that has propagated into the source repos of various projects, and we simply use that code directly, probably gets it backwards. > callPackage-style "I am a function of my dependencies" is right What did you think of Eelco's presentation at the most recent NixCon where he considers defining packages as NixOS-like modules instead of bare functions?

_huayra_ 5y ago

I really can't believe they didn't finalize Flakes in this release. The difference between it and the "standard" way of doing things is night-and-day. these sort of "secret better ways of doing things" that are not the default really frustrate and drive away new users

mikepurvis 5y ago
As another learner, I'm pretty upset about this as well. Standard install gets you nix 2.3.12 (https://nixos.org/download.html https://nixos.org/download.html), but to get flakes, you have to be on nix-2.4pre20210503_6d2553a: https://nixos.wiki/wiki/Flakes#Non-NixOS https://nixos.wiki/wiki/Flakes#Non-NixOS (And yeah, obviously all the docs are non-flake too, which leads to confusion about flake.nix vs default.nix...)
e3bc54b2 5y ago
By the way things are, I doubt they'll be stable in next release either. There were some pretty fancy things in last year's NixCon so devs might just push on that. But the problem is, many many new shiny things are so comingles with flakes that they are now stuck in limbo, thanks to the one amazing feature that was showcased back in 2019 and then rotted away in implementation hell. Initial RFC was rushed, barely discussed (there are lots of comments, but very little progress, as is the way with flakes) and then simply merged as experimental akin to pushing mess under the carpet. Well the mess was useful, but now the carpet is uneven and the first timers can barely walk straight. I just want a conclusion on flakes, any conclusion would be better than this stupid silent march.
- _huayra_ 5y ago
  I wonder if there are any contentious design decisions left in flakes. I've still new to Nix, but it seems pretty solid (the only thing I've seen is that `nix flake info` is now `nix flake metadata` or something minor). The only missing thing I've seen is how to load a repl with flake contents easily, but I usually do: nix-repl> builtins.getFlake (toString ./.) when I'm in the flake directory. It would be nice to have `nix flake repl` as well.
tazjin 5y ago
The problem with this is that flakes are currently an experiment, and one which many people in the community think has flaws that need another iteration. Making it stable now locks Nix into the current flakes model forever - it's too early for that.
- e3bc54b2 5y ago
  Agree. I think the core of the problem was that we didn't get a discussion before implementation. We got an implementation and then were given chance to discuss upon. So when the discussion pointed out flaws, since so much work was already put in, it was decided to push as experimental instead of starting from square 1. But now that implementation was available for everyone with simple flag change (a strength of Nix, if I might say), adventurers started using them. And since these adventurers have outsized impact in terms of mind share projection, the community looks divided and confuses the hell out of newcomers. I know I struggled with this because when I started learning 'The Nix Way™', flakes were the hotness and everywhere, but the documentation sucked, but still looked like they were the future so I had to wade my through anyway.
- _huayra_ 5y ago
  What part of flakes might be up for discussion? The only quirky part I see is how one has to "rewire" inputs of your own inputs (e.g. nixpkgs from an input to one's current flake) via that `follows` directive, but overall it's been rather pleasant compared to channels!

Ericson2314 5y ago

I'm glad we didn't yet stabilize because I am skeptical of a number of aspects to Nix. I suspect it's unduly popular because pure eval mode is a food idea, but there is little way to use it outside of flakes.

Ericson2314 5y ago
s/to nix/of flakes/, to be clear
- pxc 5y ago
  what do you think of the strategy of stabilizing just the input schema for Nix flakes, which is all that's required for pure evaluation, then stabilizing each component of the output schema separately as those components are called for by specific features of the Nix/NixOS CLI?
  - Ericson2314 5y ago
    That's a neat idea and improvement for sure. I'm pretty pessimistic about the outcome here, and perhaps what you said is a most realistic turn. There is a larger issue that still irks me: all this stuff is based off Cargo/Cabal/etc., but I think that's fundamentally the wrong model for our purposes. Historically every C package is a snowflake and we do need to package them individually. But as language-based ecosystems take off, we increasingly can auto generate everything we need, and our Nix code is not the bricks but the mortar. More concretely, the things I do with nix-thunk / Niv today don't really correspond to package boundaries that much, and if they do those repos might not contain any Nix code because I callCabal2nix them. callPackage-style "I am a function of my dependencies" is right, but when those dependency derivations don't align 1-1 with my nix-thunk / niv usage or need extra preprocessing à la cabal2nix, the fundamental concept of flakes breaks down.
    - pxc 5y ago
      I agree with the general orientation in favor of the monorepo and transforming package definitions from repos that don't know/care about Nix, then aggregating them. I think the vision where we use Nix mostly by way of Nix code that has propagated into the source repos of various projects, and we simply use that code directly, probably gets it backwards. > callPackage-style "I am a function of my dependencies" is right What did you think of Eelco's presentation at the most recent NixCon where he considers defining packages as NixOS-like modules instead of bare functions?