2 ms·
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.
by 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 agosure, 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.