Attendees: @thufschmitt @infinisil @fricklerhandwerk @edolstra @roberth @ericson2314 (@tomberek briefly)
Notes: @fricklerhandwerk
Agenda
- Flakes stabilisation (1h)
- CLI stabilisation (1h)
CLI stabilisation
- updated Stabilise `nix store add` · Issue #8915 · NixOS/nix · GitHub
- updated Issues · NixOS/nix · GitHub
- updated Stabilise `nix hash` and subcommands · Issue #8876 · NixOS/nix · GitHub
- open Add `nix store import` and `nix store export` commands to work with nar/narinfo · Issue #9038 · NixOS/nix · GitHub
- put some less promintent commands to the side for a second batch
Flakes stabilisation
-
state of discussion from last time:
- how much work do we want it to be? which concrete result do we aim for?
- stabilise things as they are and take on the liability of fixing things later vs. stabilising only what we can afford to support and maintain
-
@Ericson2314 thinks the best way to stabilise flakes is by peeling things off bit by bit such that they are usable in isolation
- @infinisil @fricklerhandwerk: agreed
-
@edolstra: pure eval for non-flakes is a feature request, but that’s not a blocker for stabilising flakes
-
@infinisil: stabilising requires exposing some sort of interface
-
@edolstra: agreed, the lock file format has associated semantics
-
@ericson2314: that will amount to operations to be performed on it, so there need to be additions to the stable API
-
@roberth: could take this from the ground up
- standardised how the root of the lock file is laid out, defining valid transformations
- @inifnisil: can be in a built-in or C API call
-
@roberth: could take this from the ground up
-
@ericson2314: that will amount to operations to be performed on it, so there need to be additions to the stable API
-
@edolstra: agreed, the lock file format has associated semantics
-
@edolstra: we should not expand the scope indefinitely here, otherwise we will spend years on it
- we should resist the temptation to rearchitect everything, this discussion has been done years ago
- @Ericson2314: the point is to decouple mechanisms and exposing them independently
-
@edolstra: if the outcome is to change flakes in a backwards-incompatible way, this would be destabilising
-
@roberth: we already agreed not to change flakes unnecessarily. we could commit to keep things working to a reasonable degree, but not in an absolute sense
- part of concluding the experiment is to incorporate feedback, and that didn’t happen so far
-
@roberth: we already agreed not to change flakes unnecessarily. we could commit to keep things working to a reasonable degree, but not in an absolute sense
-
@fricklerhandwerk: let’s decide if we want to stabilise features independently
- decision: yes, we will work on a non-comprehensive list of independent components that we have yet to agree on
-
fetchTreesees consensus
-
- decision: yes, we will work on a non-comprehensive list of independent components that we have yet to agree on
-
(discussed in some detail the merits of dealing with various things in isolation, without conclusion)
-
@infinisil: these seem to be a few core tenets behind this, but they are in some conflict with each other
- Nix should support existing Nix expressions indefinitely
- We should be able to improve the interface design over time
- We cannot break current uses of Flakes
-
next time: write down more things we can agree on, so we can outline a path forward