5 ms·

Should I use flakes or not? Every single library I find is a Nix Flake, but insists that Flakes are experimental. Who makes the decision that they are not exper

by n42 4y ago

Should I use flakes or not? Every single library I find is a Nix Flake, but insists that Flakes are experimental. Who makes the decision that they are not experimental? At what point does majority adoption of flakes overrule? Why are they still behind a feature flag in the CLI? What is Nickel? Is this an officially endorsed project? It’s run by Tweag — do they run Nix? Most core contributors work for Tweag. What is the fate of the Nix language? Should I start investing in this new language? Why is documentation still so bad? Why is there not a clear and official answer to documentation generation? Syntax linting? Testing? Who is in charge of trying to fix SEO for documentation? Nix is technologically sound but is struggling organizationally from its explosive growth

rgoulter 4y ago
> Should I use flakes or not? Every single library I find is a Nix Flake, but insists that Flakes are experimental. In this case, "it's experimental" should be read as "maybe the team will decide to make changes", rather than "it's not going to work half the time". e.g. one change they made was changing the property "defaultPackage" to "packages.default". (Anyway, the UX improvements from flakes are good, that once you've got the boilerplate, flakes are amazing). > Nix is technologically sound but is struggling organizationally from its explosive growth Well, that's the opposite problem of 'floundering'.
- nvln 4y ago
  > Well, that's the opposite problem of 'floundering'. +1. The explosive growth has resulted in organic blossoming of several new ideas, approaches and templates. Not all of them are great and it takes time to sift through them to see if there are canonical approaches. The creation of the team to streamline these ideas, bless some official paths is well timed.
- nonbirithm 4y ago
  >> Should I use flakes or not? Every single library I find is a Nix Flake, but insists that Flakes are experimental. > In this case, "it's experimental" should be read as "maybe the team will decide to make changes", rather than "it's not going to work half the time". This I think is part of the problem. People see the "experimental" label and don't understand that it's not "experimental" in the sense they're used to. Maybe labeling flakes as a "beta" feature and featuring the documentation more prominently would ease the confusion.
  - parminya 4y ago
    Even better would be just committing to what's there - it's so widely deployed that it's not seriously problematic. It's there to be used.
    - colordrops 4y ago
      Agreed, they should just bite the bullet and commit to flakes as enabled and not "experimental". There are plenty of other things that break regularly with my nix deployment and it's never flakes.
  - hakre 4y ago
    Perhaps the script is missing that declares what is undefined behaviour in flakes.
  - 0x457 4y ago
    Well, it is experimental. Experimental rarely means "It's not going to work and might delete your data" that what, ironically, alpha and beta mean.
- striking 4y ago
  > In this case, "it's experimental" should be read as "maybe the team will decide to make changes", rather than "it's not going to work half the time". In that case, I can't in good conscience recommend we use such a feature at my workplace. We can't afford huge breaking changes, which is what that flag suggests. Which means my workplace is stuck with a bunch of `shell.nix` and `direnv` magic instead of clean flake-based envs. It's not enough to gate features behind a flag, unless your only audience is enthusiasts. Versioning your features makes them accessible to a wider audience and encourages more risk-averse folks to adopt the features despite the possibility that they may undergo slight changes.
  - hakre 4y ago
    AFAIK you don't have to use flakes. Same as it's fine to only use shell.nix. No system is for eternity, nix builds are deterministically cached, often never reproduced, so I see no strong arguments against using direnv with shell.nix.
    - striking 4y ago
      No, we don't have to use them, but they have lots of advantages and lots of support from the community that we just can't tap into.
  - colinsane 4y ago
    > Versioning your features makes them accessible to a wider audience and encourages more risk-averse folks to adopt the features despite the possibility that they may undergo slight changes. just pin the nix package itself and that should ensure the flake API remains consistent for however many months/years you want?
    - striking 4y ago
      That creates risk when we decide to upgrade, should bugs be fixed or new tools be implemented. Right now we are up to date and hope to keep it that way.
- Arcuru 4y ago
  The Nix team doesn't allow any community proposals for making changes to Flakes because it is still 'experimental' and hasn't yet gone through an RFC. So it's 'experimental' in the sense that it might change, but the people who have suggested changes to the design are generally told that they won't discuss changes because it's not yet stabilized. That kind of circular reasoning seems problematic. Don't get me wrong, I like flakes, I use them for my NixOS setup, but the way that flakes development has been handled is very concerning.
  - rgoulter 4y ago
    > The Nix team doesn't allow any community proposals for making changes to Flakes because it is still 'experimental' and hasn't yet gone through an RFC. You sound like you have something particular in mind. If I look at the Nix RFCs, flakes was as RFC 0049 https://github.com/NixOS/rfcs/pull/49 https://github.com/NixOS/rfcs/pull/49 Maybe Alyssa's comment here? https://github.com/NixOS/rfcs/pull/136#discussion_r987278726 https://github.com/NixOS/rfcs/pull/136#discussion_r987278726
- ruuda 4y ago
  The new Nix command syntax that was there up to 2.3 was always marked as experimental, but it worked fine for many years, I used it in many projects ... until it got deleted and replaced with flakes. I really hope they don't do that again. Flakes are de facto adopted by now, if they break it once more, it will fragment the ecosystem. Though there are rough edges where a breaking change would be beneficial in the long run.
- thomastjeffery 4y ago
  > In this case, "it's experimental" should be read as "maybe the team will decide to make changes", rather than "it's not going to work half the time". This is exactly the clarification that needs to happen. It hasn't yet, and we've been needing it. That's what I mean by "floundering". Nix isn't broken, but its development progress has been needing explicit direction and clarity. That's why I'm excited to hear a team is being put together. This is a great opportunity to bring some decisiveness into Nix's development.
nvln 4y ago
SEO for Nix is kinda hard unless they decide to change the name. I've resorted to searching github with `extension:nix`, the forum and the manual directly.
- yjftsjthsd-h 4y ago
  I find "nixos" works well, even when I don't mean the Linux distro. YMMV. (And yes, I absolutely agree that if we could go back in time and change it to pretty much anything else that would be better.)
outworlder 4y ago
> explosive growth That's the opposite of floundering, no?
- callahad 4y ago
  Not necessarily... Nix is compelling enough today that it could experience explosive growth even if core development was completely stuck. If that was the case, newcomers would still find enough value to stick around and spread the word, but existing pain points would go unaddressed. I'm not close enough to Nix development to know whether this is the case or not in this instance, but the Discourse post makes a compelling argument about pull request statistics. Sibling commenters also point out that flakes have become a de facto standard despite being hidden behind an experimental flag, suggesting that the flag has lingered too long and without clear ownership or authority around stabilizing the feature. That indecision feels like floundering.
  - pxc 4y ago
    > Nix is compelling enough today that it could experience explosive growth even if core development was completely stuck. [...] I [do not] know whether this is the case It felt like that to me for a really long time, in between the releases of Nix 2.3 and 2.4, when there were lots of features being added but there was no release schedule. The divide between flakes users and non-flakes users was also larger then, as the feature was gated behind not just an experimental flag, but pre-release versions of Nix. Since then, Nix has gotten into a regular, fairly rapid release cycle and new functionality is released pretty often. There are various concerns about what that change does and doesn't fix for Nix, but for me at least there's no longer that feeling of stagnation or mystery about when Nix will see a stable update released. > flakes have become a de facto standard despite being hidden behind an experimental flag, suggesting that the flag has lingered too long and without clear ownership or authority around stabilizing the feature. That indecision feels like floundering Flakes have been conceived and pushed forward by the original author and chief maintainer of Nix. In the earliest stages of their development, consensus proved difficult to build and the community RFC process was very young. Suspending that RFC and adding the features to the master branch but marking them 'experimental' was an attempted compromise on the part of Eelco Dolstra, who had previously more or less taken a BDFL approach to maintaining Nix. Since then, the flakes implementation has matured quite a bit. I think most users expect that it will evolve into an official feature soon and without many fundamental changes, although some community members still feel some bitterness about that initial process as well as skepticism about the scope and necessity of the whole suite of features that come with flakes. At the same time, many RFCs have gone through the process since then. The organization of the projects and processes for getting ambitious changes approved are much more explicit now. In those ways, it's clear that leadership/governance in the Nix community is becoming more organized and more effective.
pxc 4y ago
These questions highlight the overwhelm that users can feel as they're getting started with Nix. The Nix ecosystem is so replete with divergent possibilities that navigating it can absolutely play into paralysis by analysis, and lead users to hesitate to learn more because they don't know where to start or which competing tools in the ecosystem are more suitable or more likely to be 'the future'. That is an experience of floundering for sure. But in terms of contributions, capabilities, and userbase, the Nix lately been subject to impressive and exciting growth that you mention. I think the best is yet to come, but it's already fair to say that Nix is flourishing. The community and the codebases also do have growing pains, of course. But I don't think that Nix is floundering at all.

by n42 4y ago

rgoulter 4y ago

> Should I use flakes or not? Every single library I find is a Nix Flake, but insists that Flakes are experimental. In this case, "it's experimental" should be read as "maybe the team will decide to make changes", rather than "it's not going to work half the time". e.g. one change they made was changing the property "defaultPackage" to "packages.default". (Anyway, the UX improvements from flakes are good, that once you've got the boilerplate, flakes are amazing). > Nix is technologically sound but is struggling organizationally from its explosive growth Well, that's the opposite problem of 'floundering'.

nvln 4y ago
> Well, that's the opposite problem of 'floundering'. +1. The explosive growth has resulted in organic blossoming of several new ideas, approaches and templates. Not all of them are great and it takes time to sift through them to see if there are canonical approaches. The creation of the team to streamline these ideas, bless some official paths is well timed.
nonbirithm 4y ago
>> Should I use flakes or not? Every single library I find is a Nix Flake, but insists that Flakes are experimental. > In this case, "it's experimental" should be read as "maybe the team will decide to make changes", rather than "it's not going to work half the time". This I think is part of the problem. People see the "experimental" label and don't understand that it's not "experimental" in the sense they're used to. Maybe labeling flakes as a "beta" feature and featuring the documentation more prominently would ease the confusion.
- parminya 4y ago
  Even better would be just committing to what's there - it's so widely deployed that it's not seriously problematic. It's there to be used.
  - colordrops 4y ago
    Agreed, they should just bite the bullet and commit to flakes as enabled and not "experimental". There are plenty of other things that break regularly with my nix deployment and it's never flakes.
- hakre 4y ago
  Perhaps the script is missing that declares what is undefined behaviour in flakes.
- 0x457 4y ago
  Well, it is experimental. Experimental rarely means "It's not going to work and might delete your data" that what, ironically, alpha and beta mean.
striking 4y ago
> In this case, "it's experimental" should be read as "maybe the team will decide to make changes", rather than "it's not going to work half the time". In that case, I can't in good conscience recommend we use such a feature at my workplace. We can't afford huge breaking changes, which is what that flag suggests. Which means my workplace is stuck with a bunch of `shell.nix` and `direnv` magic instead of clean flake-based envs. It's not enough to gate features behind a flag, unless your only audience is enthusiasts. Versioning your features makes them accessible to a wider audience and encourages more risk-averse folks to adopt the features despite the possibility that they may undergo slight changes.
- hakre 4y ago
  AFAIK you don't have to use flakes. Same as it's fine to only use shell.nix. No system is for eternity, nix builds are deterministically cached, often never reproduced, so I see no strong arguments against using direnv with shell.nix.
  - striking 4y ago
    No, we don't have to use them, but they have lots of advantages and lots of support from the community that we just can't tap into.
- colinsane 4y ago
  > Versioning your features makes them accessible to a wider audience and encourages more risk-averse folks to adopt the features despite the possibility that they may undergo slight changes. just pin the nix package itself and that should ensure the flake API remains consistent for however many months/years you want?
  - striking 4y ago
    That creates risk when we decide to upgrade, should bugs be fixed or new tools be implemented. Right now we are up to date and hope to keep it that way.
Arcuru 4y ago
The Nix team doesn't allow any community proposals for making changes to Flakes because it is still 'experimental' and hasn't yet gone through an RFC. So it's 'experimental' in the sense that it might change, but the people who have suggested changes to the design are generally told that they won't discuss changes because it's not yet stabilized. That kind of circular reasoning seems problematic. Don't get me wrong, I like flakes, I use them for my NixOS setup, but the way that flakes development has been handled is very concerning.
- rgoulter 4y ago
  > The Nix team doesn't allow any community proposals for making changes to Flakes because it is still 'experimental' and hasn't yet gone through an RFC. You sound like you have something particular in mind. If I look at the Nix RFCs, flakes was as RFC 0049 https://github.com/NixOS/rfcs/pull/49 https://github.com/NixOS/rfcs/pull/49 Maybe Alyssa's comment here? https://github.com/NixOS/rfcs/pull/136#discussion_r987278726 https://github.com/NixOS/rfcs/pull/136#discussion_r987278726
ruuda 4y ago
The new Nix command syntax that was there up to 2.3 was always marked as experimental, but it worked fine for many years, I used it in many projects ... until it got deleted and replaced with flakes. I really hope they don't do that again. Flakes are de facto adopted by now, if they break it once more, it will fragment the ecosystem. Though there are rough edges where a breaking change would be beneficial in the long run.
thomastjeffery 4y ago
> In this case, "it's experimental" should be read as "maybe the team will decide to make changes", rather than "it's not going to work half the time". This is exactly the clarification that needs to happen. It hasn't yet, and we've been needing it. That's what I mean by "floundering". Nix isn't broken, but its development progress has been needing explicit direction and clarity. That's why I'm excited to hear a team is being put together. This is a great opportunity to bring some decisiveness into Nix's development.

nvln 4y ago

SEO for Nix is kinda hard unless they decide to change the name. I've resorted to searching github with `extension:nix`, the forum and the manual directly.

yjftsjthsd-h 4y ago
I find "nixos" works well, even when I don't mean the Linux distro. YMMV. (And yes, I absolutely agree that if we could go back in time and change it to pretty much anything else that would be better.)

outworlder 4y ago

> explosive growth That's the opposite of floundering, no?

callahad 4y ago
Not necessarily... Nix is compelling enough today that it could experience explosive growth even if core development was completely stuck. If that was the case, newcomers would still find enough value to stick around and spread the word, but existing pain points would go unaddressed. I'm not close enough to Nix development to know whether this is the case or not in this instance, but the Discourse post makes a compelling argument about pull request statistics. Sibling commenters also point out that flakes have become a de facto standard despite being hidden behind an experimental flag, suggesting that the flag has lingered too long and without clear ownership or authority around stabilizing the feature. That indecision feels like floundering.
- pxc 4y ago
  > Nix is compelling enough today that it could experience explosive growth even if core development was completely stuck. [...] I [do not] know whether this is the case It felt like that to me for a really long time, in between the releases of Nix 2.3 and 2.4, when there were lots of features being added but there was no release schedule. The divide between flakes users and non-flakes users was also larger then, as the feature was gated behind not just an experimental flag, but pre-release versions of Nix. Since then, Nix has gotten into a regular, fairly rapid release cycle and new functionality is released pretty often. There are various concerns about what that change does and doesn't fix for Nix, but for me at least there's no longer that feeling of stagnation or mystery about when Nix will see a stable update released. > flakes have become a de facto standard despite being hidden behind an experimental flag, suggesting that the flag has lingered too long and without clear ownership or authority around stabilizing the feature. That indecision feels like floundering Flakes have been conceived and pushed forward by the original author and chief maintainer of Nix. In the earliest stages of their development, consensus proved difficult to build and the community RFC process was very young. Suspending that RFC and adding the features to the master branch but marking them 'experimental' was an attempted compromise on the part of Eelco Dolstra, who had previously more or less taken a BDFL approach to maintaining Nix. Since then, the flakes implementation has matured quite a bit. I think most users expect that it will evolve into an official feature soon and without many fundamental changes, although some community members still feel some bitterness about that initial process as well as skepticism about the scope and necessity of the whole suite of features that come with flakes. At the same time, many RFCs have gone through the process since then. The organization of the projects and processes for getting ambitious changes approved are much more explicit now. In those ways, it's clear that leadership/governance in the Nix community is becoming more organized and more effective.

pxc 4y ago

These questions highlight the overwhelm that users can feel as they're getting started with Nix. The Nix ecosystem is so replete with divergent possibilities that navigating it can absolutely play into paralysis by analysis, and lead users to hesitate to learn more because they don't know where to start or which competing tools in the ecosystem are more suitable or more likely to be 'the future'. That is an experience of floundering for sure. But in terms of contributions, capabilities, and userbase, the Nix lately been subject to impressive and exciting growth that you mention. I think the best is yet to come, but it's already fair to say that Nix is flourishing. The community and the codebases also do have growing pains, of course. But I don't think that Nix is floundering at all.