5 ms·

> 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

> 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

> 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.