3 ms·

> Versioning your features makes them accessible to a wider audience and encourages more risk-averse folks to adopt the features despite the possibility that th

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

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.