3 ms·

> 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

> 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.
  - colinsane 4y ago
    sure, there’s risk in any direction. > Which means my workplace is stuck with a bunch of `shell.nix` and `direnv` magic instead of clean flake-based envs. if flakes win out, this other stuff might well be deprecated someday. timeline for that is probably lengthier than the timeline where flakes don’t win, but it’s still there. in either scenario you’re gonna have a month or more between one approach being deprecated and being dropped altogether (6 months if you’re on the stable channel). you’re implicitly betting for or against the success of flakes here, weighted by the cost of refactoring should you bet on the “losing” side plus maintenance until the winner emerges. you describe non-flake maintenance as being higher cost, so from the outside it just feels like a suspicious bet to make.
  - rgoulter 4y ago
    > That creates risk when we decide to upgrade, should bugs be fixed or new tools be implemented. This is true of literally any dependency, though. Semver is supposed to grant you confidence that things won't change very much, but it's not a technical guarantee. In terms of "risk of adopting nix flakes", the lion's share of the risk is in "adopting nix" (because nix is difficult, hard to find people well versed in nix, etc.). The risks from adopting flakes on top of that are marginal.

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.
- colinsane 4y ago
  sure, there’s risk in any direction. > Which means my workplace is stuck with a bunch of `shell.nix` and `direnv` magic instead of clean flake-based envs. if flakes win out, this other stuff might well be deprecated someday. timeline for that is probably lengthier than the timeline where flakes don’t win, but it’s still there. in either scenario you’re gonna have a month or more between one approach being deprecated and being dropped altogether (6 months if you’re on the stable channel). you’re implicitly betting for or against the success of flakes here, weighted by the cost of refactoring should you bet on the “losing” side plus maintenance until the winner emerges. you describe non-flake maintenance as being higher cost, so from the outside it just feels like a suspicious bet to make.
- rgoulter 4y ago
  > That creates risk when we decide to upgrade, should bugs be fixed or new tools be implemented. This is true of literally any dependency, though. Semver is supposed to grant you confidence that things won't change very much, but it's not a technical guarantee. In terms of "risk of adopting nix flakes", the lion's share of the risk is in "adopting nix" (because nix is difficult, hard to find people well versed in nix, etc.). The risks from adopting flakes on top of that are marginal.