From 0a97c81cf5f57a070c91ed3f27f2bb48ab62a38f Mon Sep 17 00:00:00 2001 From: John Ericson Date: Thu, 15 Sep 2022 12:32:12 -0400 Subject: [PATCH 01/35] stabilize-incrementally: Copy template --- rfcs/0000-stabilize-incrementally.md | 58 ++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 rfcs/0000-stabilize-incrementally.md diff --git a/rfcs/0000-stabilize-incrementally.md b/rfcs/0000-stabilize-incrementally.md new file mode 100644 index 000000000..43569cf57 --- /dev/null +++ b/rfcs/0000-stabilize-incrementally.md @@ -0,0 +1,58 @@ +--- +feature: (fill me in with a unique ident, my_awesome_feature) +start-date: (fill me in with today's date, YYYY-MM-DD) +author: (name of the main author) +co-authors: (find a buddy later to help out with the RFC) +shepherd-team: (names, to be nominated and accepted by RFC steering committee) +shepherd-leader: (name to be appointed by RFC steering committee) +related-issues: (will contain links to implementation PRs) +--- + +# Summary +[summary]: #summary + +One paragraph explanation of the feature. + +# Motivation +[motivation]: #motivation + +Why are we doing this? What use cases does it support? What is the expected +outcome? + +# Detailed design +[design]: #detailed-design + +This is the core, normative part of the RFC. Explain the design in enough +detail for somebody familiar with the ecosystem to understand, and implement. +This should get into specifics and corner-cases. Yet, this section should also +be terse, avoiding redundancy even at the cost of clarity. + +# Examples and Interactions +[examples-and-interactions]: #examples-and-interactions + +This section illustrates the detailed design. This section should clarify all +confusion the reader has from the previous sections. It is especially important +to counterbalance the desired terseness of the detailed design; if you feel +your detailed design is rudely short, consider making this section longer +instead. + +# Drawbacks +[drawbacks]: #drawbacks + +Why should we *not* do this? + +# Alternatives +[alternatives]: #alternatives + +What other designs have been considered? What is the impact of not doing this? + +# Unresolved questions +[unresolved]: #unresolved-questions + +What parts of the design are still TBD or unknowns? + +# Future work +[future]: #future-work + +What future work, if any, would be implied or impacted by this feature +without being directly part of the work? From 6a8dedc18222e0fff00f92098d35cedf228fbaf8 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Thu, 15 Sep 2022 14:00:05 -0400 Subject: [PATCH 02/35] stabilize-incrementally: First Draft --- rfcs/0000-stabilize-incrementally.md | 171 +++++++++++++++++++++++---- 1 file changed, 151 insertions(+), 20 deletions(-) diff --git a/rfcs/0000-stabilize-incrementally.md b/rfcs/0000-stabilize-incrementally.md index 43569cf57..0accbe86c 100644 --- a/rfcs/0000-stabilize-incrementally.md +++ b/rfcs/0000-stabilize-incrementally.md @@ -1,7 +1,7 @@ --- -feature: (fill me in with a unique ident, my_awesome_feature) -start-date: (fill me in with today's date, YYYY-MM-DD) -author: (name of the main author) +feature: stabilize-incrementally +start-date: 2022-09-15 +author: John Ericson co-authors: (find a buddy later to help out with the RFC) shepherd-team: (names, to be nominated and accepted by RFC steering committee) shepherd-leader: (name to be appointed by RFC steering committee) @@ -11,48 +11,179 @@ related-issues: (will contain links to implementation PRs) # Summary [summary]: #summary -One paragraph explanation of the feature. +Stabilize the new command line interface and Flakes in an incremental fashion, leveraging [RFC 134](https://github.com/NixOS/rfcs/pull/134). +This plan is designed to still efficiently end the current "limbo" era of these unstable yet widely-used features, yet also soothe the longstanding tensions in the Nix community over how we got here. # Motivation [motivation]: #motivation -Why are we doing this? What use cases does it support? What is the expected -outcome? +For the past few years, we've accumulated a massive backlog of unstable features in the form of the new command-line interface and flakes. +There is now a growing desire to stabilize those features, but as of yet no plan on exactly how to do so. +The tension between that desire and a lack of a clear plan has loomed over our heads for a while; this RFC aims to dispel it by providing a concrete plan, an plan that hopefully will mitigate the lingering controversies and tensions around Flakes. + +## The situation so far + +There are a few facts that must be introduced to give context to this situation. +We can't change these short of a time machine, so we must find a way to live wit them instead.x + +### Flakes are very popular + +As measured in the community polls, Nix has a lot of new users, dwarfing the number of long-time users. +Flakes is very popular among these new users. +Ergo, Flakes is very popular among the Nix community as a whole. + +Like it or not, these users have been using Flakes as if it was stable, and we cannot make huge drastic changes that would break their code in hard-to-fix ways. + +Many Groups and individuals interested in the continued growth the Nix community see Flakes are popular, an also wish it to be stabilized to attract further still more users, since Flakes are already proven to be popular among users. + +### Difficulties in the roll-out + +It is undeniable that the roll-out of these new features has been controversial. +Graham Christensen's blog post [flakes-are-an-obviously-good-thing](https://grahamc.com/blog/flakes-are-an-obviously-good-thing) lays out the procedure issues along the way quite well. + +Some people were upset the Flakes RFC was abandoned but the feature merged. +Other people were fine with experimental features being merged without RFC, but were upset because Flakes never really *felt* experimental. +Experimental features would be modified a lot subject to community design use, and, most importantly, *discouraged* from being used in production. + +### Flakes are criticized for encroaching on other features + +There are many criticism about Flakes. +But one of them especially relevant to stabilizing is a perception that Flakes have encroached on other new features, in the sense that it ought to be possible to use them without Flakes but isn't in practice. +For example, there is no reason in theory pure eval requires Flakes, but without the ability to populate an initial whitelist of store paths that are safe to import it in practice does. + +This is especially noticeable for new CLI features that *previously did*, in fact, work without Flakes. +For example, in earlier versions of Nix `nix search` worked without Flakes. + +## A plan all sides can be happy with + +Stabilizing the new CLI and Flakes will end the saga of the past few years. +It is a last good chance to sooth some of these tensions and put us on a good foot moving forward. +The new NixOS Foundation gives me hope Nix is serious about addressing these sorts of governance issues, and thus would be a good way to further demonstrate we are turning a new leaf. + +The plan below attempts to make all sides happy, despite their seemingly irreconcilable differences. +The basic thrust is to proceed with stabilization in small steps. +Two benefits are envisioned: + +### Benefit 1: Keep discussions on track. + +Threads on Flakes in the past have been impossible to follow because the sheer magnitude of different topics being discussed. +Small stabilization steps are meant to yield *focused, bounded* discussions that actually read well. +This also ensures any issues that do arise are actually brought to attention, and not lost within a deluge of other topics. + +### Benefit 2: Build trust by starting with the least controversial material. + +Flakes are obviously the most controversial, and so they are saved for last. +The CLI is more broadly popular, but still is a lot of material to discuss. +The store-only subcommands are Nix's "plumbing" as opposed to "porcelain" commands, and thus have the simplest (if not most user-friendly) purposes. +This "dusty corner" off the new CLI is rather calm with a very constrained design space, and far less acrimony. + +## Conclusion + +By starting with these relatively easy material to stabilize, we can prove we can all come together as a community to agree on a design after all. +This should build trust between opposing individuals and factions, giving us a foundation upon which to tackle the more challenging material in subsequent steps. + +since these features became very popular while they are still unstable, there is now both an urgency to stabilize them, and little ability to modify them. +This is the opposite of how experimental features are supposed to leisurely incubate with both plenty of flexibility to change them, and little rush to stabilize them until they feel ready. +But, there is little we can do about this at this point, an this RFC recognizes that fact and does *not* try to resist it. + +But, we have crossed that Rubicon and there is no turning back; this RFC *doesn't* attempt to change Flakes or the command line # Detailed design [design]: #detailed-design -This is the core, normative part of the RFC. Explain the design in enough -detail for somebody familiar with the ecosystem to understand, and implement. -This should get into specifics and corner-cases. Yet, this section should also -be terse, avoiding redundancy even at the cost of clarity. +Step 1 is technical work, with a self-imposed deadline so we can be sure it doesn't delay stabilization too long. +The remaining steps are stabilization steps. +For each of them, a separate RFC or other discussion medium will describe the new interfaces to be stabilized, and solicit feedback. + +## Step 1: Split out a store-only Nix, with deadline + +This is the same as step one from [RFC 134](https://github.com/NixOS/rfcs/pull/134), upon which this RFC depends. + +A deadline is imposed to get that complete, so agreement on this stabilization plan is guaranteed not to add more than a small bounded delay as opposed to stabilizing everything immediately. + +## Step 2: Stabilize the store-only Nix CLI + +If the deadline for step 1 is met, then we stabilize *just* the command-line interface of the store-only Nix command. + +This is a small portion of the total amount of interface we have to stabilize, and that will hopefully yield a narrow and more focused discussion. +Yet it will still offer some interesting topics to discus, such as: + +- logging +- store paths on `stdout` at end of build? +- Should commands like `show-derivation` should use `--json` by default +- Flat vs hierarchical commands +- is `--derivation` a good flag? + +## Step 3: Stabilize the rest of the CLI, without Flakes + +If the deadline for step 1 is *not* met, we jump directly to this step, skipping step 2. + +This is rest off the new CLI, without flakes. +Unlike the store-only Nix command which has yet to be implemented, this is easy to visual today by enabling the `nix-command` feature without the `flakes` feature. +This is a chance to discuss topics like: + +- Is `--file` good, or should we be able to specify something like `file#attribute` to mix files and attributes? (Without using Flakes.) +- Should all outputs be selected if one writes `foo.dev`? +- How can `nix repl` have a more normal CLI? + +## Step 4: Stabilize Flakes itself + +Finally, with the other less controversial interfaces stabilized, we can tackle the Flakes itself, the one remainder. # Examples and Interactions [examples-and-interactions]: #examples-and-interactions -This section illustrates the detailed design. This section should clarify all -confusion the reader has from the previous sections. It is especially important -to counterbalance the desired terseness of the detailed design; if you feel -your detailed design is rudely short, consider making this section longer -instead. +Having laid out the plan, let us now return to how the current situation is characterized and see if the various facts that the factions orient themselves are respected. + +## Flakes are very popular + +And they will be stabilized, with minimal delay. + +Firstly, there is no feature work proposed in the interim --- the splitting of Nix is just partitioning existing functionality, with some behind-the-scenes refactors needed to make that possible. +The deadline placed on that work also assuages those concerned about the current "limbo" that stabilization will be gotten to no matter what, even if the splitting fails, after a set amount of time. + +## Difficulties in the roll-out + +Process concerns are addressed by having a clear process, with clear outcomes, before any stabilization is begun. +That is the purpose of this RFC! + +## Flakes are criticized for eating other Nix features + +We do *not* propose adding delay to once-again separate those features from Flakes, as that would introduce more feature work which would delay stabilization and be unacceptable to the pro-Flakes faction. + +That said, an ancillary incremental process of incremental stabilization is to bolster a *sense* of layering in Nix's user interface that has been, according to this camp, lost. +Ensuring that the these two subsets of the new CLI --- without lakes, and without Nix language support --- do in fact make sense in isolation will provide a "scaffolding" upon which interested parties can later introduce generalized features like search and pure eval without Flakes. + +The hope is that such scaffolding will assuage this faction their concerns are heard without holding things up. # Drawbacks [drawbacks]: #drawbacks -Why should we *not* do this? +The main downside is a small delay from the splitting Nix process, and then delay between the stabilization steps. + +The first delay has a guaranteed upper bound, thanks to its self-imposed deadline. +That maximum delay should be dwarfed by duration of time we've spent "in limbo" without a clear plan to move forward. +I therefore think that is a small and reasonable price to pay for the benefit of community harmony. + +The second delays don't represent time "ideal" from a stabilization perspective. +As long as we are making progress stabilizing features and having healthy discussions, I don't see any problem. # Alternatives [alternatives]: #alternatives -What other designs have been considered? What is the impact of not doing this? +Of course, we could instead count on the magnitude of new years making the concerns of old users unimportant, but I think the plan here has little downsides; we can instead make everyone happy with only a small delay. +If that is true, why not do that instead! +A plan to stabilize F # Unresolved questions [unresolved]: #unresolved-questions -What parts of the design are still TBD or unknowns? +How long should the deadline for creating the store-only Nix be? # Future work [future]: #future-work -What future work, if any, would be implied or impacted by this feature -without being directly part of the work? +Generalization features to work without Flakes, like pure eval and search, might be desired by the Flake-skeptic faction, but is purposely left as future work in order to not delay stabilization. + +We could have a no-Flakes Nix just as we have a no-eval Nix, given every step of stabilization an minimal Nix executable with just the stabilized commands implemented. +This is also left as future work to avoid controversy and minimize delay. From ce46413ab24f92e7e0e55f604cf41eb294e4b821 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Mon, 3 Oct 2022 12:41:57 -0400 Subject: [PATCH 03/35] stabilize-incrementally: Move RFC into position --- ...stabilize-incrementally.md => 0136-stabilize-incrementally.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename rfcs/{0000-stabilize-incrementally.md => 0136-stabilize-incrementally.md} (100%) diff --git a/rfcs/0000-stabilize-incrementally.md b/rfcs/0136-stabilize-incrementally.md similarity index 100% rename from rfcs/0000-stabilize-incrementally.md rename to rfcs/0136-stabilize-incrementally.md From 2f151ef5e17b8a18d57747dc0ff0d68733d5e891 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Mon, 3 Oct 2022 14:37:20 -0400 Subject: [PATCH 04/35] stabilize-incrementally: Fix typo Thanks @0x4A6F! --- rfcs/0136-stabilize-incrementally.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0136-stabilize-incrementally.md b/rfcs/0136-stabilize-incrementally.md index 0accbe86c..78b452d38 100644 --- a/rfcs/0136-stabilize-incrementally.md +++ b/rfcs/0136-stabilize-incrementally.md @@ -152,7 +152,7 @@ That is the purpose of this RFC! We do *not* propose adding delay to once-again separate those features from Flakes, as that would introduce more feature work which would delay stabilization and be unacceptable to the pro-Flakes faction. That said, an ancillary incremental process of incremental stabilization is to bolster a *sense* of layering in Nix's user interface that has been, according to this camp, lost. -Ensuring that the these two subsets of the new CLI --- without lakes, and without Nix language support --- do in fact make sense in isolation will provide a "scaffolding" upon which interested parties can later introduce generalized features like search and pure eval without Flakes. +Ensuring that the these two subsets of the new CLI --- without Flakes, and without Nix language support --- do in fact make sense in isolation will provide a "scaffolding" upon which interested parties can later introduce generalized features like search and pure eval without Flakes. The hope is that such scaffolding will assuage this faction their concerns are heard without holding things up. From 509e2f1e8ddac2b6269c4784db559c22c0acaf08 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Tue, 4 Oct 2022 16:38:21 -0400 Subject: [PATCH 05/35] Apply suggestions from code review --- rfcs/0136-stabilize-incrementally.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0136-stabilize-incrementally.md b/rfcs/0136-stabilize-incrementally.md index 78b452d38..e7eebd699 100644 --- a/rfcs/0136-stabilize-incrementally.md +++ b/rfcs/0136-stabilize-incrementally.md @@ -173,7 +173,7 @@ As long as we are making progress stabilizing features and having healthy discus Of course, we could instead count on the magnitude of new years making the concerns of old users unimportant, but I think the plan here has little downsides; we can instead make everyone happy with only a small delay. If that is true, why not do that instead! -A plan to stabilize F +That is what this plan is trying to be. # Unresolved questions [unresolved]: #unresolved-questions From 49abe39ea68a6c495fd87170de8a11e7b72f8eab Mon Sep 17 00:00:00 2001 From: John Ericson Date: Thu, 6 Oct 2022 16:25:27 -0400 Subject: [PATCH 06/35] stabilize-incrementally: Fix typo! Thanks! Co-authored-by: sternenseemann --- rfcs/0136-stabilize-incrementally.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0136-stabilize-incrementally.md b/rfcs/0136-stabilize-incrementally.md index e7eebd699..a0db6a45d 100644 --- a/rfcs/0136-stabilize-incrementally.md +++ b/rfcs/0136-stabilize-incrementally.md @@ -82,7 +82,7 @@ This "dusty corner" off the new CLI is rather calm with a very constrained desig By starting with these relatively easy material to stabilize, we can prove we can all come together as a community to agree on a design after all. This should build trust between opposing individuals and factions, giving us a foundation upon which to tackle the more challenging material in subsequent steps. -since these features became very popular while they are still unstable, there is now both an urgency to stabilize them, and little ability to modify them. +Since these features became very popular while they are still unstable, there is now both an urgency to stabilize them, and little ability to modify them. This is the opposite of how experimental features are supposed to leisurely incubate with both plenty of flexibility to change them, and little rush to stabilize them until they feel ready. But, there is little we can do about this at this point, an this RFC recognizes that fact and does *not* try to resist it. From 4113118467498d5df7e995363cfe9024373625b8 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Tue, 17 Jan 2023 12:25:02 -0500 Subject: [PATCH 07/35] stabilize-incrementally: There are easy thing we can do do first! --- rfcs/0136-stabilize-incrementally.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/rfcs/0136-stabilize-incrementally.md b/rfcs/0136-stabilize-incrementally.md index a0db6a45d..3ead65179 100644 --- a/rfcs/0136-stabilize-incrementally.md +++ b/rfcs/0136-stabilize-incrementally.md @@ -95,6 +95,13 @@ Step 1 is technical work, with a self-imposed deadline so we can be sure it does The remaining steps are stabilization steps. For each of them, a separate RFC or other discussion medium will describe the new interfaces to be stabilized, and solicit feedback. +## Step 0: Stabilize the store-only installable-free CLI + +There are certain commands like `nix store gc`, `nix store ping` that do not take any positional arguments. +As @roberth elsewhere pointed out, because these commands have so few degrees of freedom, they are some of the easiest to stabilize --- there is simply less to pour over and possibly bikeshed. + +We can start stabilizing them right away, either in a batch, or one by one. + ## Step 1: Split out a store-only Nix, with deadline This is the same as step one from [RFC 134](https://github.com/NixOS/rfcs/pull/134), upon which this RFC depends. @@ -168,6 +175,8 @@ I therefore think that is a small and reasonable price to pay for the benefit of The second delays don't represent time "ideal" from a stabilization perspective. As long as we are making progress stabilizing features and having healthy discussions, I don't see any problem. +**Step 0** is also designed to take the preasure off these this, giving us *something* to work on that is not blocked on RFC 134 or anything else. + # Alternatives [alternatives]: #alternatives From 1181c57e4185a0e9bbd3465654b7834a41b4c76c Mon Sep 17 00:00:00 2001 From: John Ericson Date: Mon, 23 Jan 2023 09:16:07 -0500 Subject: [PATCH 08/35] stabilize-incrementally: Word-smith --- rfcs/0136-stabilize-incrementally.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/rfcs/0136-stabilize-incrementally.md b/rfcs/0136-stabilize-incrementally.md index 3ead65179..56af39671 100644 --- a/rfcs/0136-stabilize-incrementally.md +++ b/rfcs/0136-stabilize-incrementally.md @@ -175,14 +175,15 @@ I therefore think that is a small and reasonable price to pay for the benefit of The second delays don't represent time "ideal" from a stabilization perspective. As long as we are making progress stabilizing features and having healthy discussions, I don't see any problem. -**Step 0** is also designed to take the preasure off these this, giving us *something* to work on that is not blocked on RFC 134 or anything else. +**Step 0** is also designed to take the pressure off these possible sources of delay, giving us *something* to work on that is not blocked on RFC 134 or anything else. # Alternatives [alternatives]: #alternatives -Of course, we could instead count on the magnitude of new years making the concerns of old users unimportant, but I think the plan here has little downsides; we can instead make everyone happy with only a small delay. +We could, of course, just "rip off the band-aid" and stabilize everything at once. +The argument for that would be that enough time has passed and the concerns of (less numerous) long-time users are not important. +But I think the plan here has little downsides; we can instead make everyone happy with only a small delay. If that is true, why not do that instead! -That is what this plan is trying to be. # Unresolved questions [unresolved]: #unresolved-questions From 921ea84ac5cf3df12f23325bdcd88e208626f16e Mon Sep 17 00:00:00 2001 From: John Ericson Date: Fri, 27 Jan 2023 12:27:21 -0500 Subject: [PATCH 09/35] 136: Apply suggestions from code review Thanks! Co-authored-by: asymmetric --- rfcs/0136-stabilize-incrementally.md | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/rfcs/0136-stabilize-incrementally.md b/rfcs/0136-stabilize-incrementally.md index 56af39671..4e9b0f7ce 100644 --- a/rfcs/0136-stabilize-incrementally.md +++ b/rfcs/0136-stabilize-incrementally.md @@ -57,8 +57,8 @@ For example, in earlier versions of Nix `nix search` worked without Flakes. ## A plan all sides can be happy with Stabilizing the new CLI and Flakes will end the saga of the past few years. -It is a last good chance to sooth some of these tensions and put us on a good foot moving forward. -The new NixOS Foundation gives me hope Nix is serious about addressing these sorts of governance issues, and thus would be a good way to further demonstrate we are turning a new leaf. +It is a last good chance to soothe some of these tensions and put us on a good foot moving forward. +The new NixOS Foundation gives the RFC authors hope Nix is serious about addressing these sorts of governance issues, and thus would be a good way to further demonstrate we are turning a new leaf. The plan below attempts to make all sides happy, despite their seemingly irreconcilable differences. The basic thrust is to proceed with stabilization in small steps. @@ -66,7 +66,7 @@ Two benefits are envisioned: ### Benefit 1: Keep discussions on track. -Threads on Flakes in the past have been impossible to follow because the sheer magnitude of different topics being discussed. +Threads on Flakes in the past, such as that for the [original RFC](https://github.com/NixOS/rfcs/pull/49), have been impossible to follow because the sheer magnitude of different topics being discussed. Small stabilization steps are meant to yield *focused, bounded* discussions that actually read well. This also ensures any issues that do arise are actually brought to attention, and not lost within a deluge of other topics. @@ -75,18 +75,18 @@ This also ensures any issues that do arise are actually brought to attention, an Flakes are obviously the most controversial, and so they are saved for last. The CLI is more broadly popular, but still is a lot of material to discuss. The store-only subcommands are Nix's "plumbing" as opposed to "porcelain" commands, and thus have the simplest (if not most user-friendly) purposes. -This "dusty corner" off the new CLI is rather calm with a very constrained design space, and far less acrimony. +This "dusty corner" of the new CLI is rather calm with a very constrained design space, and far less acrimony. ## Conclusion -By starting with these relatively easy material to stabilize, we can prove we can all come together as a community to agree on a design after all. +By starting with this relatively easy material to stabilize, we can prove we can all come together as a community to agree on a design after all. This should build trust between opposing individuals and factions, giving us a foundation upon which to tackle the more challenging material in subsequent steps. Since these features became very popular while they are still unstable, there is now both an urgency to stabilize them, and little ability to modify them. This is the opposite of how experimental features are supposed to leisurely incubate with both plenty of flexibility to change them, and little rush to stabilize them until they feel ready. But, there is little we can do about this at this point, an this RFC recognizes that fact and does *not* try to resist it. -But, we have crossed that Rubicon and there is no turning back; this RFC *doesn't* attempt to change Flakes or the command line +But, we have crossed that Rubicon and there is no turning back; this RFC *doesn't* attempt to change Flakes or the command line. # Detailed design [design]: #detailed-design @@ -117,7 +117,7 @@ Yet it will still offer some interesting topics to discus, such as: - logging - store paths on `stdout` at end of build? -- Should commands like `show-derivation` should use `--json` by default +- Should commands like `show-derivation` use `--json` by default? - Flat vs hierarchical commands - is `--derivation` a good flag? @@ -125,8 +125,8 @@ Yet it will still offer some interesting topics to discus, such as: If the deadline for step 1 is *not* met, we jump directly to this step, skipping step 2. -This is rest off the new CLI, without flakes. -Unlike the store-only Nix command which has yet to be implemented, this is easy to visual today by enabling the `nix-command` feature without the `flakes` feature. +This is the rest off the new CLI, without flakes. +Unlike the store-only Nix command which has yet to be implemented, this is easy to visualize today by enabling the `nix-command` feature without the `flakes` feature. This is a chance to discuss topics like: - Is `--file` good, or should we be able to specify something like `file#attribute` to mix files and attributes? (Without using Flakes.) @@ -159,7 +159,7 @@ That is the purpose of this RFC! We do *not* propose adding delay to once-again separate those features from Flakes, as that would introduce more feature work which would delay stabilization and be unacceptable to the pro-Flakes faction. That said, an ancillary incremental process of incremental stabilization is to bolster a *sense* of layering in Nix's user interface that has been, according to this camp, lost. -Ensuring that the these two subsets of the new CLI --- without Flakes, and without Nix language support --- do in fact make sense in isolation will provide a "scaffolding" upon which interested parties can later introduce generalized features like search and pure eval without Flakes. +Ensuring that these two subsets of the new CLI --- without Flakes, and without Nix language support --- do in fact make sense in isolation will provide a "scaffolding" upon which interested parties can later introduce generalized features like search and pure eval without Flakes. The hope is that such scaffolding will assuage this faction their concerns are heard without holding things up. @@ -170,10 +170,10 @@ The main downside is a small delay from the splitting Nix process, and then dela The first delay has a guaranteed upper bound, thanks to its self-imposed deadline. That maximum delay should be dwarfed by duration of time we've spent "in limbo" without a clear plan to move forward. -I therefore think that is a small and reasonable price to pay for the benefit of community harmony. +We therefore think that is a small and reasonable price to pay for the benefit of community harmony. The second delays don't represent time "ideal" from a stabilization perspective. -As long as we are making progress stabilizing features and having healthy discussions, I don't see any problem. +As long as we are making progress stabilizing features and having healthy discussions, we don't see any problem. **Step 0** is also designed to take the pressure off these possible sources of delay, giving us *something* to work on that is not blocked on RFC 134 or anything else. @@ -182,7 +182,7 @@ As long as we are making progress stabilizing features and having healthy discus We could, of course, just "rip off the band-aid" and stabilize everything at once. The argument for that would be that enough time has passed and the concerns of (less numerous) long-time users are not important. -But I think the plan here has little downsides; we can instead make everyone happy with only a small delay. +But we think the plan here has little downsides; we can instead make everyone happy with only a small delay. If that is true, why not do that instead! # Unresolved questions From 2d26b8df0e5f399bcb402004d24cee389e5f338e Mon Sep 17 00:00:00 2001 From: John Ericson Date: Thu, 2 Feb 2023 09:19:56 -0500 Subject: [PATCH 10/35] 0136: Fix typo Thanks! Co-authored-by: Andreas Rammhold --- rfcs/0136-stabilize-incrementally.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0136-stabilize-incrementally.md b/rfcs/0136-stabilize-incrementally.md index 4e9b0f7ce..3b52a7b6b 100644 --- a/rfcs/0136-stabilize-incrementally.md +++ b/rfcs/0136-stabilize-incrementally.md @@ -24,7 +24,7 @@ The tension between that desire and a lack of a clear plan has loomed over our h ## The situation so far There are a few facts that must be introduced to give context to this situation. -We can't change these short of a time machine, so we must find a way to live wit them instead.x +We can't change these short of a time machine, so we must find a way to live wit them instead. ### Flakes are very popular From 6e6ed87c0602e2945571a51bff7fb88afa9ff603 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Thu, 2 Feb 2023 09:20:43 -0500 Subject: [PATCH 11/35] 136: Fix typo --- rfcs/0136-stabilize-incrementally.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0136-stabilize-incrementally.md b/rfcs/0136-stabilize-incrementally.md index 3b52a7b6b..eb680355f 100644 --- a/rfcs/0136-stabilize-incrementally.md +++ b/rfcs/0136-stabilize-incrementally.md @@ -24,7 +24,7 @@ The tension between that desire and a lack of a clear plan has loomed over our h ## The situation so far There are a few facts that must be introduced to give context to this situation. -We can't change these short of a time machine, so we must find a way to live wit them instead. +We can't change these short of a time machine, so we must find a way to live with them instead. ### Flakes are very popular From 1b9710c1f6b80f01ebaf6bd9c4cc05a4e60e4554 Mon Sep 17 00:00:00 2001 From: Eelco Dolstra Date: Wed, 22 Feb 2023 15:55:43 +0100 Subject: [PATCH 12/35] Add shepherds --- rfcs/0136-stabilize-incrementally.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rfcs/0136-stabilize-incrementally.md b/rfcs/0136-stabilize-incrementally.md index eb680355f..1b66e16a4 100644 --- a/rfcs/0136-stabilize-incrementally.md +++ b/rfcs/0136-stabilize-incrementally.md @@ -3,8 +3,8 @@ feature: stabilize-incrementally start-date: 2022-09-15 author: John Ericson co-authors: (find a buddy later to help out with the RFC) -shepherd-team: (names, to be nominated and accepted by RFC steering committee) -shepherd-leader: (name to be appointed by RFC steering committee) +shepherd-team: @thufschmitt @tomberek @infinisil +shepherd-leader: @tomberek related-issues: (will contain links to implementation PRs) --- From ab194b10e54624050cee9785c189dcfca3499d08 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Thu, 2 Mar 2023 16:10:00 -0500 Subject: [PATCH 13/35] 136: Make clear we are not stablizing as-is --- rfcs/0136-stabilize-incrementally.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/rfcs/0136-stabilize-incrementally.md b/rfcs/0136-stabilize-incrementally.md index 1b66e16a4..755c0d6f1 100644 --- a/rfcs/0136-stabilize-incrementally.md +++ b/rfcs/0136-stabilize-incrementally.md @@ -95,7 +95,7 @@ Step 1 is technical work, with a self-imposed deadline so we can be sure it does The remaining steps are stabilization steps. For each of them, a separate RFC or other discussion medium will describe the new interfaces to be stabilized, and solicit feedback. -## Step 0: Stabilize the store-only installable-free CLI +## Step 0: Audit, refine, and stabilize the store-only installable-free CLI There are certain commands like `nix store gc`, `nix store ping` that do not take any positional arguments. As @roberth elsewhere pointed out, because these commands have so few degrees of freedom, they are some of the easiest to stabilize --- there is simply less to pour over and possibly bikeshed. @@ -108,7 +108,7 @@ This is the same as step one from [RFC 134](https://github.com/NixOS/rfcs/pull/1 A deadline is imposed to get that complete, so agreement on this stabilization plan is guaranteed not to add more than a small bounded delay as opposed to stabilizing everything immediately. -## Step 2: Stabilize the store-only Nix CLI +## Step 2: Audit, refine, and stabilize the store-only Nix CLI If the deadline for step 1 is met, then we stabilize *just* the command-line interface of the store-only Nix command. @@ -121,7 +121,7 @@ Yet it will still offer some interesting topics to discus, such as: - Flat vs hierarchical commands - is `--derivation` a good flag? -## Step 3: Stabilize the rest of the CLI, without Flakes +## Step 3: Audit, refine, and stabilize the rest of the CLI, without Flakes If the deadline for step 1 is *not* met, we jump directly to this step, skipping step 2. @@ -133,7 +133,7 @@ This is a chance to discuss topics like: - Should all outputs be selected if one writes `foo.dev`? - How can `nix repl` have a more normal CLI? -## Step 4: Stabilize Flakes itself +## Step 4: Audit, refine, and stabilize Flakes itself Finally, with the other less controversial interfaces stabilized, we can tackle the Flakes itself, the one remainder. From 5e13c236d6a02097c3f6a449104c1463463f6dcb Mon Sep 17 00:00:00 2001 From: John Ericson Date: Thu, 2 Mar 2023 16:13:19 -0500 Subject: [PATCH 14/35] 136: Attempt second split --- rfcs/0136-stabilize-incrementally.md | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/rfcs/0136-stabilize-incrementally.md b/rfcs/0136-stabilize-incrementally.md index 755c0d6f1..1f3c43d6d 100644 --- a/rfcs/0136-stabilize-incrementally.md +++ b/rfcs/0136-stabilize-incrementally.md @@ -121,7 +121,12 @@ Yet it will still offer some interesting topics to discus, such as: - Flat vs hierarchical commands - is `--derivation` a good flag? -## Step 3: Audit, refine, and stabilize the rest of the CLI, without Flakes +## Step 3: Attempt likewise splitting a nix lang without flakes Nix CLI + +For the same reason that a store-only Nix is useful for validating the store-only CLI, and ensuring it works with many *possible* higher layers, it is also useful to build a Store + Nix lang -only Nix without Flakes. +Whether it or not it is possible to actually do this is left to the Nix Team to decide, but it should be at least considered/attempted. + +## Step 4: Audit, refine, and stabilize the rest of the CLI, without Flakes If the deadline for step 1 is *not* met, we jump directly to this step, skipping step 2. @@ -133,7 +138,7 @@ This is a chance to discuss topics like: - Should all outputs be selected if one writes `foo.dev`? - How can `nix repl` have a more normal CLI? -## Step 4: Audit, refine, and stabilize Flakes itself +## Step 5: Audit, refine, and stabilize Flakes itself Finally, with the other less controversial interfaces stabilized, we can tackle the Flakes itself, the one remainder. From c79cc3e7155f0808fc57104570e6b0c0f9bc2e53 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Thu, 2 Mar 2023 16:14:54 -0500 Subject: [PATCH 15/35] 136: Fix typo Added a word by mistake --- rfcs/0136-stabilize-incrementally.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0136-stabilize-incrementally.md b/rfcs/0136-stabilize-incrementally.md index 1f3c43d6d..47b3b153f 100644 --- a/rfcs/0136-stabilize-incrementally.md +++ b/rfcs/0136-stabilize-incrementally.md @@ -121,7 +121,7 @@ Yet it will still offer some interesting topics to discus, such as: - Flat vs hierarchical commands - is `--derivation` a good flag? -## Step 3: Attempt likewise splitting a nix lang without flakes Nix CLI +## Step 3: Attempt likewise splitting a nix lang without flakes Nix For the same reason that a store-only Nix is useful for validating the store-only CLI, and ensuring it works with many *possible* higher layers, it is also useful to build a Store + Nix lang -only Nix without Flakes. Whether it or not it is possible to actually do this is left to the Nix Team to decide, but it should be at least considered/attempted. From beaaf5a3ae5a7b6c67f1c2ec6e440731d29d1cbb Mon Sep 17 00:00:00 2001 From: John Ericson Date: Thu, 2 Mar 2023 16:23:23 -0500 Subject: [PATCH 16/35] 136: Explicate that stabilizing Flakes requires future RFCs --- rfcs/0136-stabilize-incrementally.md | 1 + 1 file changed, 1 insertion(+) diff --git a/rfcs/0136-stabilize-incrementally.md b/rfcs/0136-stabilize-incrementally.md index 47b3b153f..1c0068963 100644 --- a/rfcs/0136-stabilize-incrementally.md +++ b/rfcs/0136-stabilize-incrementally.md @@ -141,6 +141,7 @@ This is a chance to discuss topics like: ## Step 5: Audit, refine, and stabilize Flakes itself Finally, with the other less controversial interfaces stabilized, we can tackle the Flakes itself, the one remainder. +This will require future RFCs. # Examples and Interactions [examples-and-interactions]: #examples-and-interactions From 9a1ff22936dd921b7c52b62510697e0e3609f4cd Mon Sep 17 00:00:00 2001 From: John Ericson Date: Fri, 10 Mar 2023 11:51:12 -0500 Subject: [PATCH 17/35] 136: Clean up relationship to 134 - Make clear it is accepted - Make clear the implementation on it is well underway, and PRs have already been merged. - Remove language about deadline and skipping steps if deadline is not met, as it is confusing and hopefully not necessary. - Instead include more open-ended language about reconsidering the dependencies if unexpected delays with the split do arise. --- rfcs/0136-stabilize-incrementally.md | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/rfcs/0136-stabilize-incrementally.md b/rfcs/0136-stabilize-incrementally.md index 1c0068963..690b9f905 100644 --- a/rfcs/0136-stabilize-incrementally.md +++ b/rfcs/0136-stabilize-incrementally.md @@ -102,15 +102,18 @@ As @roberth elsewhere pointed out, because these commands have so few degrees of We can start stabilizing them right away, either in a batch, or one by one. -## Step 1: Split out a store-only Nix, with deadline +## Step 1: Split out a store-only Nix -This is the same as step one from [RFC 134](https://github.com/NixOS/rfcs/pull/134), upon which this RFC depends. +This is detailed design from (accepted) [RFC 134](./0134-nix-store-layer.md). -A deadline is imposed to get that complete, so agreement on this stabilization plan is guaranteed not to add more than a small bounded delay as opposed to stabilizing everything immediately. +The point of this step is not to re-open the already accepted decision to make the split, but to say it SHOULD be completed at this point. +In other words, step 0 is free to begin immediately, but steps 2 and beyond are blocked on finishing this. + +The implementation of the split is already mostly complete, and preperatory improvements have already been merged, but if unforseen issues arise finishing it, we can reconsider the dependency on this step from step 2. ## Step 2: Audit, refine, and stabilize the store-only Nix CLI -If the deadline for step 1 is met, then we stabilize *just* the command-line interface of the store-only Nix command. +Stabilize *just* the command-line interface of the store-only Nix command. This is a small portion of the total amount of interface we have to stabilize, and that will hopefully yield a narrow and more focused discussion. Yet it will still offer some interesting topics to discus, such as: @@ -128,8 +131,6 @@ Whether it or not it is possible to actually do this is left to the Nix Team to ## Step 4: Audit, refine, and stabilize the rest of the CLI, without Flakes -If the deadline for step 1 is *not* met, we jump directly to this step, skipping step 2. - This is the rest off the new CLI, without flakes. Unlike the store-only Nix command which has yet to be implemented, this is easy to visualize today by enabling the `nix-command` feature without the `flakes` feature. This is a chance to discuss topics like: @@ -153,7 +154,7 @@ Having laid out the plan, let us now return to how the current situation is char And they will be stabilized, with minimal delay. Firstly, there is no feature work proposed in the interim --- the splitting of Nix is just partitioning existing functionality, with some behind-the-scenes refactors needed to make that possible. -The deadline placed on that work also assuages those concerned about the current "limbo" that stabilization will be gotten to no matter what, even if the splitting fails, after a set amount of time. +The earlier steps have been carefully designed to be either easier or already started ("de-risked") to assuagee those that are concerned about the current "limbo" that stabilization will be gotten to no matter what, even if the splitting fails. ## Difficulties in the roll-out @@ -174,8 +175,8 @@ The hope is that such scaffolding will assuage this faction their concerns are h The main downside is a small delay from the splitting Nix process, and then delay between the stabilization steps. -The first delay has a guaranteed upper bound, thanks to its self-imposed deadline. -That maximum delay should be dwarfed by duration of time we've spent "in limbo" without a clear plan to move forward. +The fact that 134 is already mostly implemented, and in code review, is hopefully reason enough to believe it shouldn't take much longer. +That maximum delay waiting for that to complete should be dwarfed by duration of time we've spent "in limbo" without a clear plan to move forward. We therefore think that is a small and reasonable price to pay for the benefit of community harmony. The second delays don't represent time "ideal" from a stabilization perspective. @@ -194,7 +195,7 @@ If that is true, why not do that instead! # Unresolved questions [unresolved]: #unresolved-questions -How long should the deadline for creating the store-only Nix be? +None at this time. # Future work [future]: #future-work From abf0819538548bccd625ba2df67fb1a343e68724 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Fri, 10 Mar 2023 11:59:15 -0500 Subject: [PATCH 18/35] 136: Clarify drawback more, fix typos --- rfcs/0136-stabilize-incrementally.md | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/rfcs/0136-stabilize-incrementally.md b/rfcs/0136-stabilize-incrementally.md index 690b9f905..28b325106 100644 --- a/rfcs/0136-stabilize-incrementally.md +++ b/rfcs/0136-stabilize-incrementally.md @@ -11,7 +11,7 @@ related-issues: (will contain links to implementation PRs) # Summary [summary]: #summary -Stabilize the new command line interface and Flakes in an incremental fashion, leveraging [RFC 134](https://github.com/NixOS/rfcs/pull/134). +Stabilize the new command line interface and Flakes in an incremental fashion, leveraging [RFC 134]. This plan is designed to still efficiently end the current "limbo" era of these unstable yet widely-used features, yet also soothe the longstanding tensions in the Nix community over how we got here. # Motivation @@ -104,12 +104,12 @@ We can start stabilizing them right away, either in a batch, or one by one. ## Step 1: Split out a store-only Nix -This is detailed design from (accepted) [RFC 134](./0134-nix-store-layer.md). +This is detailed design from (accepted) [RFC 134]. The point of this step is not to re-open the already accepted decision to make the split, but to say it SHOULD be completed at this point. In other words, step 0 is free to begin immediately, but steps 2 and beyond are blocked on finishing this. -The implementation of the split is already mostly complete, and preperatory improvements have already been merged, but if unforseen issues arise finishing it, we can reconsider the dependency on this step from step 2. +The implementation of the split is already mostly complete, and preparatory improvements have already been merged, but if unforeseen issues arise finishing it, we can reconsider the dependency on this step from step 2. ## Step 2: Audit, refine, and stabilize the store-only Nix CLI @@ -175,14 +175,16 @@ The hope is that such scaffolding will assuage this faction their concerns are h The main downside is a small delay from the splitting Nix process, and then delay between the stabilization steps. -The fact that 134 is already mostly implemented, and in code review, is hopefully reason enough to believe it shouldn't take much longer. +The fact that [RFC 134] is already mostly implemented, and in code review, is hopefully reason enough to believe it shouldn't take much longer. That maximum delay waiting for that to complete should be dwarfed by duration of time we've spent "in limbo" without a clear plan to move forward. We therefore think that is a small and reasonable price to pay for the benefit of community harmony. -The second delays don't represent time "ideal" from a stabilization perspective. +An addition, in the detailed design there is an escape hatch saying that blocking on the implementation of [RFC 134] can be reconsidered things do indeed take longer than foreseen. + +The delay of "auditing and refining" and shouldn't represent time "idle" from a stabilization perspective. As long as we are making progress stabilizing features and having healthy discussions, we don't see any problem. -**Step 0** is also designed to take the pressure off these possible sources of delay, giving us *something* to work on that is not blocked on RFC 134 or anything else. +**Step 0** is also designed to take the pressure off these possible sources of delay, giving us *something* to work on that is not blocked on [RFC 134] or anything else. # Alternatives [alternatives]: #alternatives @@ -204,3 +206,5 @@ Generalization features to work without Flakes, like pure eval and search, might We could have a no-Flakes Nix just as we have a no-eval Nix, given every step of stabilization an minimal Nix executable with just the stabilized commands implemented. This is also left as future work to avoid controversy and minimize delay. + +[RFC 134]: ./0134-nix-store-layer.md From 9ad0f90b000344d5992d2f038e17a7ccb6205687 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Fri, 10 Mar 2023 12:21:17 -0500 Subject: [PATCH 19/35] 136: Beef up detailed design with reusable process --- rfcs/0136-stabilize-incrementally.md | 66 ++++++++++++++++++++++++---- 1 file changed, 57 insertions(+), 9 deletions(-) diff --git a/rfcs/0136-stabilize-incrementally.md b/rfcs/0136-stabilize-incrementally.md index 28b325106..005b57de2 100644 --- a/rfcs/0136-stabilize-incrementally.md +++ b/rfcs/0136-stabilize-incrementally.md @@ -91,18 +91,66 @@ But, we have crossed that Rubicon and there is no turning back; this RFC *doesn' # Detailed design [design]: #detailed-design +First we describe how stabilization should work in general. +Then we describe the order in which things are stabilized. +Finally we combine both into a list of step. + +## The general stabilization process --- audit, refine, and *then* stabilze + +Stabilization is not a matter of just flipping a switch on an implementation that has accrued for a period of time. +Because the moment before stabilization is our last chance to make major changes, it is crucial that we look over what is being stabilized. + +To stabilize a piece of function we must do these things: + +1. **Audit the functionality** + + Making note of the current state. + Do this publicly so the Nix community writ large has a chance to weigh in. + +2. **Propose refinements of the functionality** + + It is reasonable to notice things that were not noticed before the audit. + Features can either be changed, or they can be carefully carved out as ineligible for stabilization at this time, and left to be dealt with in a later round of this process. + + Note that for large, complex, and controversial features, an RFC is also required (per usual) to advance to the next step. + The acceptance of the RFC concludes the "propose refinements" step. + +3. **Create a "release candidate"** + + It should be possible to enable just the experimental that is ready for stabilization *in isolation*, without also enabling other unstable functionality. + This is important to allow users (and tests!) to try it out and make sure it is a meaningful feature in its own right, and not just a partially-complete things that relies on the further unstable features. + + If we have an RFC, the release candidate experimental feature should match the RFC. + +4. **Actually stabilize** + + Only this last step is "stabilization proper". + +## CLI in waves, then Flakes + +As discussed in the motivation, we want to stabilize the less controversial Flake-agnostic new CLI before Flakes. +In addition, the CLI can itself be split up for more fine-grained rounds of stabilization. + +The rounds thus look like this: + +1. CLI + 1. "installable"-free Store-only CLI + 2. Rest of the Store-only CLI (includes "derived path" installables) + 3. Rest of the flake-agnostic CLI +2. Flakes + +## Combined plan + Step 1 is technical work, with a self-imposed deadline so we can be sure it doesn't delay stabilization too long. The remaining steps are stabilization steps. For each of them, a separate RFC or other discussion medium will describe the new interfaces to be stabilized, and solicit feedback. -## Step 0: Audit, refine, and stabilize the store-only installable-free CLI +### Step 0: Audit, refine, and stabilize the store-only installable-free CLI There are certain commands like `nix store gc`, `nix store ping` that do not take any positional arguments. -As @roberth elsewhere pointed out, because these commands have so few degrees of freedom, they are some of the easiest to stabilize --- there is simply less to pour over and possibly bikeshed. - -We can start stabilizing them right away, either in a batch, or one by one. +As @roberth elsewhere pointed out, because these commands have so few degrees of freedom, they are some of the easiest to stabilize --- there is simply less to pour over and possibly bike-shed. -## Step 1: Split out a store-only Nix +### Step 1: Split out a store-only Nix This is detailed design from (accepted) [RFC 134]. @@ -111,7 +159,7 @@ In other words, step 0 is free to begin immediately, but steps 2 and beyond are The implementation of the split is already mostly complete, and preparatory improvements have already been merged, but if unforeseen issues arise finishing it, we can reconsider the dependency on this step from step 2. -## Step 2: Audit, refine, and stabilize the store-only Nix CLI +### Step 2: Audit, refine, and stabilize the store-only Nix CLI Stabilize *just* the command-line interface of the store-only Nix command. @@ -124,12 +172,12 @@ Yet it will still offer some interesting topics to discus, such as: - Flat vs hierarchical commands - is `--derivation` a good flag? -## Step 3: Attempt likewise splitting a nix lang without flakes Nix +### Step 3: Attempt likewise splitting a nix lang without flakes Nix For the same reason that a store-only Nix is useful for validating the store-only CLI, and ensuring it works with many *possible* higher layers, it is also useful to build a Store + Nix lang -only Nix without Flakes. Whether it or not it is possible to actually do this is left to the Nix Team to decide, but it should be at least considered/attempted. -## Step 4: Audit, refine, and stabilize the rest of the CLI, without Flakes +### Step 4: Audit, refine, and stabilize the rest of the CLI, without Flakes This is the rest off the new CLI, without flakes. Unlike the store-only Nix command which has yet to be implemented, this is easy to visualize today by enabling the `nix-command` feature without the `flakes` feature. @@ -139,7 +187,7 @@ This is a chance to discuss topics like: - Should all outputs be selected if one writes `foo.dev`? - How can `nix repl` have a more normal CLI? -## Step 5: Audit, refine, and stabilize Flakes itself +### Step 5: Audit, refine, and stabilize Flakes itself Finally, with the other less controversial interfaces stabilized, we can tackle the Flakes itself, the one remainder. This will require future RFCs. From 4b32f7dd0234eb5d242df3015ff58cff063ef7d5 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Fri, 10 Mar 2023 13:11:54 -0500 Subject: [PATCH 20/35] 136: Apply suggestions from code review Thanks! Co-authored-by: Valentin Gagarin --- rfcs/0136-stabilize-incrementally.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/rfcs/0136-stabilize-incrementally.md b/rfcs/0136-stabilize-incrementally.md index 005b57de2..bdb909d8b 100644 --- a/rfcs/0136-stabilize-incrementally.md +++ b/rfcs/0136-stabilize-incrementally.md @@ -34,7 +34,7 @@ Ergo, Flakes is very popular among the Nix community as a whole. Like it or not, these users have been using Flakes as if it was stable, and we cannot make huge drastic changes that would break their code in hard-to-fix ways. -Many Groups and individuals interested in the continued growth the Nix community see Flakes are popular, an also wish it to be stabilized to attract further still more users, since Flakes are already proven to be popular among users. +Many Groups and individuals interested in the continued growth the Nix community see Flakes are popular, an also wish it to be stabilized to attract still more users, since Flakes are already proven to be popular among users. ### Difficulties in the roll-out @@ -43,13 +43,14 @@ Graham Christensen's blog post [flakes-are-an-obviously-good-thing](https://grah Some people were upset the Flakes RFC was abandoned but the feature merged. Other people were fine with experimental features being merged without RFC, but were upset because Flakes never really *felt* experimental. -Experimental features would be modified a lot subject to community design use, and, most importantly, *discouraged* from being used in production. +Experimental features are expected to be subject to community feedback, modified a lot based upon that feedback, and, most importantly, *discouraged* from being used in production. ### Flakes are criticized for encroaching on other features There are many criticism about Flakes. But one of them especially relevant to stabilizing is a perception that Flakes have encroached on other new features, in the sense that it ought to be possible to use them without Flakes but isn't in practice. -For example, there is no reason in theory pure eval requires Flakes, but without the ability to populate an initial whitelist of store paths that are safe to import it in practice does. +For example, there is no reason in theory that pure evaluation if Nix expressions requires Flakes. +But without the ability to populate some sort of initial list of store paths that are safe to import, pure evaluation in practice does require Flakes. This is especially noticeable for new CLI features that *previously did*, in fact, work without Flakes. For example, in earlier versions of Nix `nix search` worked without Flakes. @@ -58,7 +59,7 @@ For example, in earlier versions of Nix `nix search` worked without Flakes. Stabilizing the new CLI and Flakes will end the saga of the past few years. It is a last good chance to soothe some of these tensions and put us on a good foot moving forward. -The new NixOS Foundation gives the RFC authors hope Nix is serious about addressing these sorts of governance issues, and thus would be a good way to further demonstrate we are turning a new leaf. +The new NixOS Foundation gives the RFC authors hope that the Nix community is serious about addressing these sorts of governance issues, and accepting this RFC would be a good way to further demonstrate we are turning a new leaf. The plan below attempts to make all sides happy, despite their seemingly irreconcilable differences. The basic thrust is to proceed with stabilization in small steps. @@ -174,8 +175,8 @@ Yet it will still offer some interesting topics to discus, such as: ### Step 3: Attempt likewise splitting a nix lang without flakes Nix -For the same reason that a store-only Nix is useful for validating the store-only CLI, and ensuring it works with many *possible* higher layers, it is also useful to build a Store + Nix lang -only Nix without Flakes. -Whether it or not it is possible to actually do this is left to the Nix Team to decide, but it should be at least considered/attempted. +For the same reason that a store-only Nix is useful for validating the store-only CLI, and ensuring it works with many *possible* higher layers, it is also useful to build a store-and-language-only Nix without Flakes. +Whether or not it is possible to actually do this is left to the Nix Team to decide, but it should be at least considered. ### Step 4: Audit, refine, and stabilize the rest of the CLI, without Flakes From ce6cc82e09d120a56328b73fb07e781235a59c42 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Sun, 12 Mar 2023 10:05:39 -0400 Subject: [PATCH 21/35] 136: A few misc things --- rfcs/0136-stabilize-incrementally.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/rfcs/0136-stabilize-incrementally.md b/rfcs/0136-stabilize-incrementally.md index bdb909d8b..9bde9844a 100644 --- a/rfcs/0136-stabilize-incrementally.md +++ b/rfcs/0136-stabilize-incrementally.md @@ -108,6 +108,8 @@ To stabilize a piece of function we must do these things: Making note of the current state. Do this publicly so the Nix community writ large has a chance to weigh in. + The features to be stabilized should "stand alone", meaning that they should make sense and work both with and without further unstable features not yet undergoing the stabilization process. + 2. **Propose refinements of the functionality** It is reasonable to notice things that were not noticed before the audit. @@ -167,11 +169,11 @@ Stabilize *just* the command-line interface of the store-only Nix command. This is a small portion of the total amount of interface we have to stabilize, and that will hopefully yield a narrow and more focused discussion. Yet it will still offer some interesting topics to discus, such as: -- logging -- store paths on `stdout` at end of build? +- Logging +- Store paths on `stdout` at end of build? - Should commands like `show-derivation` use `--json` by default? - Flat vs hierarchical commands -- is `--derivation` a good flag? +- is `--derivation` a good flag? ([Nix issue #7261](https://github.com/NixOS/nix/issues/7261)) ### Step 3: Attempt likewise splitting a nix lang without flakes Nix @@ -185,7 +187,7 @@ Unlike the store-only Nix command which has yet to be implemented, this is easy This is a chance to discuss topics like: - Is `--file` good, or should we be able to specify something like `file#attribute` to mix files and attributes? (Without using Flakes.) -- Should all outputs be selected if one writes `foo.dev`? +- ~~Should all outputs be selected if one writes `foo.dev`?~~ Since fixed. - How can `nix repl` have a more normal CLI? ### Step 5: Audit, refine, and stabilize Flakes itself From 53f4c69b2c3a31f99ca60c2672d16f2e4dead06e Mon Sep 17 00:00:00 2001 From: John Ericson Date: Thu, 16 Mar 2023 16:56:11 -0400 Subject: [PATCH 22/35] 136: Remove "no-Flakes Nix" from future work It is now an optional step in the RFC proper. --- rfcs/0136-stabilize-incrementally.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/rfcs/0136-stabilize-incrementally.md b/rfcs/0136-stabilize-incrementally.md index 9bde9844a..fa15912f3 100644 --- a/rfcs/0136-stabilize-incrementally.md +++ b/rfcs/0136-stabilize-incrementally.md @@ -255,7 +255,4 @@ None at this time. Generalization features to work without Flakes, like pure eval and search, might be desired by the Flake-skeptic faction, but is purposely left as future work in order to not delay stabilization. -We could have a no-Flakes Nix just as we have a no-eval Nix, given every step of stabilization an minimal Nix executable with just the stabilized commands implemented. -This is also left as future work to avoid controversy and minimize delay. - [RFC 134]: ./0134-nix-store-layer.md From 509e1d10addf2b043f09e1e26777150ea1d8ccc1 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Thu, 16 Mar 2023 16:59:05 -0400 Subject: [PATCH 23/35] 136: Remove the infamous "like it or not..." By popular demand! --- rfcs/0136-stabilize-incrementally.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/rfcs/0136-stabilize-incrementally.md b/rfcs/0136-stabilize-incrementally.md index fa15912f3..78a97099e 100644 --- a/rfcs/0136-stabilize-incrementally.md +++ b/rfcs/0136-stabilize-incrementally.md @@ -32,8 +32,6 @@ As measured in the community polls, Nix has a lot of new users, dwarfing the num Flakes is very popular among these new users. Ergo, Flakes is very popular among the Nix community as a whole. -Like it or not, these users have been using Flakes as if it was stable, and we cannot make huge drastic changes that would break their code in hard-to-fix ways. - Many Groups and individuals interested in the continued growth the Nix community see Flakes are popular, an also wish it to be stabilized to attract still more users, since Flakes are already proven to be popular among users. ### Difficulties in the roll-out From e1b741b56257334b26e3ebe6b06f91c1c6196593 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Thu, 16 Mar 2023 17:41:55 -0400 Subject: [PATCH 24/35] 136: Retitle some stesp for clarity --- rfcs/0136-stabilize-incrementally.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/rfcs/0136-stabilize-incrementally.md b/rfcs/0136-stabilize-incrementally.md index 78a97099e..11ead034a 100644 --- a/rfcs/0136-stabilize-incrementally.md +++ b/rfcs/0136-stabilize-incrementally.md @@ -173,14 +173,14 @@ Yet it will still offer some interesting topics to discus, such as: - Flat vs hierarchical commands - is `--derivation` a good flag? ([Nix issue #7261](https://github.com/NixOS/nix/issues/7261)) -### Step 3: Attempt likewise splitting a nix lang without flakes Nix +### Step 3: Attempt likewise splitting a store-and-language-only Nix -For the same reason that a store-only Nix is useful for validating the store-only CLI, and ensuring it works with many *possible* higher layers, it is also useful to build a store-and-language-only Nix without Flakes. +For the same reason that a store-only Nix is useful for validating the store-only CLI, and ensuring it works with many *possible* higher layers, it is also useful to build a store-and-language-only Nix, without Flakes. Whether or not it is possible to actually do this is left to the Nix Team to decide, but it should be at least considered. -### Step 4: Audit, refine, and stabilize the rest of the CLI, without Flakes +### Step 4: Audit, refine, and stabilize the store-and-language-only Nix CLI -This is the rest off the new CLI, without flakes. +This is the rest off the new CLI, without Flakes. Unlike the store-only Nix command which has yet to be implemented, this is easy to visualize today by enabling the `nix-command` feature without the `flakes` feature. This is a chance to discuss topics like: From ca44ef6707cf6f8dbda6f016c08bb9e4752b6241 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Thu, 16 Mar 2023 18:23:33 -0400 Subject: [PATCH 25/35] 136: Slight reword --- rfcs/0136-stabilize-incrementally.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0136-stabilize-incrementally.md b/rfcs/0136-stabilize-incrementally.md index 11ead034a..ba230d017 100644 --- a/rfcs/0136-stabilize-incrementally.md +++ b/rfcs/0136-stabilize-incrementally.md @@ -214,7 +214,7 @@ That is the purpose of this RFC! We do *not* propose adding delay to once-again separate those features from Flakes, as that would introduce more feature work which would delay stabilization and be unacceptable to the pro-Flakes faction. -That said, an ancillary incremental process of incremental stabilization is to bolster a *sense* of layering in Nix's user interface that has been, according to this camp, lost. +That said, an ancillary incremental beneift of incremental stabilization is to bolster a *sense* of layering in Nix's user interface that has been, according to some people, lost. Ensuring that these two subsets of the new CLI --- without Flakes, and without Nix language support --- do in fact make sense in isolation will provide a "scaffolding" upon which interested parties can later introduce generalized features like search and pure eval without Flakes. The hope is that such scaffolding will assuage this faction their concerns are heard without holding things up. From 2ea03b305cba1f6c678c12f09c24ac5ea8a4b554 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Thu, 6 Apr 2023 18:04:44 -0400 Subject: [PATCH 26/35] 136: Layering principles and other changes from meeting today Collaborative editting is nice! --- rfcs/0136-stabilize-incrementally.md | 104 +++++++++++++++++++++++++-- 1 file changed, 98 insertions(+), 6 deletions(-) diff --git a/rfcs/0136-stabilize-incrementally.md b/rfcs/0136-stabilize-incrementally.md index ba230d017..b6c7065e0 100644 --- a/rfcs/0136-stabilize-incrementally.md +++ b/rfcs/0136-stabilize-incrementally.md @@ -17,6 +17,11 @@ This plan is designed to still efficiently end the current "limbo" era of these # Motivation [motivation]: #motivation +Rewrite: +Nix currently has a somewhat layered interface, but this is a mere implementation detail. +Users of Nix could easily never know this. + +Old: For the past few years, we've accumulated a massive backlog of unstable features in the form of the new command-line interface and flakes. There is now a growing desire to stabilize those features, but as of yet no plan on exactly how to do so. The tension between that desire and a lack of a clear plan has loomed over our heads for a while; this RFC aims to dispel it by providing a concrete plan, an plan that hopefully will mitigate the lingering controversies and tensions around Flakes. @@ -45,13 +50,13 @@ Experimental features are expected to be subject to community feedback, modified ### Flakes are criticized for encroaching on other features -There are many criticism about Flakes. +There are many criticisms about Flakes. But one of them especially relevant to stabilizing is a perception that Flakes have encroached on other new features, in the sense that it ought to be possible to use them without Flakes but isn't in practice. For example, there is no reason in theory that pure evaluation if Nix expressions requires Flakes. But without the ability to populate some sort of initial list of store paths that are safe to import, pure evaluation in practice does require Flakes. This is especially noticeable for new CLI features that *previously did*, in fact, work without Flakes. -For example, in earlier versions of Nix `nix search` worked without Flakes. +For example, in earlier versions of Nix, `nix search` worked without Flakes. ## A plan all sides can be happy with @@ -90,9 +95,61 @@ But, we have crossed that Rubicon and there is no turning back; this RFC *doesn' # Detailed design [design]: #detailed-design -First we describe how stabilization should work in general. +> TODO out of date summary + +~~First we describe how stabilization should work in general. Then we describe the order in which things are stabilized. -Finally we combine both into a list of step. +Finally we combine both into a list of step.~~ + +This RFC consists of these parts: +- Establishing basic layering principles +- Define the different layers of Nix +- Make Nix conform to these layers + +## Layering principles + +These basic layering principles will be added to the [Nix architecture documentation](https://nixos.org/manual/nix/stable/architecture/architecture.html): + +- **Public-ity** + + Layers are not just an implementation detail, instead they are publically exposed to the user via stable interfaces + - All exposed interfaces in Nix, both for computers or humans, must be matched to layers + - TODO: Move these to a stability section + - These exposed interfaces must conform to stability guarantees + - Functionality of layers must be either be stable or be marked as experimental, in which case breaking changes may happen + - The user has the option (it need not be mandatory!) to be aware of the layering and use it to learn Nix + - Both perspectives are equally valid, and neither is prioritized over the other + - While not going so far as to *insist* users are aware of layering and care about it, the layered archicture of Nix should be exposed to anyone that cares, and it shouldn't suddenly dissapear (as a mere implementation detail might). + +- **Clarity of purpose** + + layers should not be too thick. + layers should "do one thing, and do it well". + +- **Modularity** + + One can replace the implementation of the layer with a different one, while using the same implemenations of any layers above and below. + + This is desirable but not currently required. E.g.: + + - There does exist multiple stores, that should continue to work (and work better than it does today) + - We don't care about being able to swap out the evaluator in C++ Nix, however we *do* care that the language is defined well enough that other implementation of the Nix language is possible. + +- **Gravity** + + features should be in the lowest layer it makes sense to have them + +- **Compositionality** + + layers should stand the alone: + - They should work as the top layer + - They should work expose a clear interface so it is possible to build multiple possible layers on top. + +### Implementation + +Nix currently marks experimental features in a formal way, which is excellent. +Nix should likewise mark deprecated features in a formal way. +It is good to be able to disable deprecated features before they removed to *prepare* for future breaking changes. ## The general stabilization process --- audit, refine, and *then* stabilze @@ -131,6 +188,7 @@ To stabilize a piece of function we must do these things: As discussed in the motivation, we want to stabilize the less controversial Flake-agnostic new CLI before Flakes. In addition, the CLI can itself be split up for more fine-grained rounds of stabilization. +According to the layering principles, the CLI in fact *must* be split in order to abide by the **publicity** principle. The rounds thus look like this: @@ -188,16 +246,48 @@ This is a chance to discuss topics like: - ~~Should all outputs be selected if one writes `foo.dev`?~~ Since fixed. - How can `nix repl` have a more normal CLI? +Following the **gravity** principle, we will eventually want to pure eval and eval caching to be possible and easy to use without flakes; they should become part of this layer. +The stabilized CLI must "make room" for these features becoming part of this layer. + ### Step 5: Audit, refine, and stabilize Flakes itself Finally, with the other less controversial interfaces stabilized, we can tackle the Flakes itself, the one remainder. This will require future RFCs. +As stated in the previous step, following the **gravity**, pure eval and eval caching should be possible and easy to use without flakes. +Ideally, by the time we get to this step, that is accomplished. +If it isn't, we should at least make sure that it will be possible to do so later. +It is OK to stabilize features that violate the layering principles, *only* so long as their stability does not impede fixing those violations later. + # Examples and Interactions [examples-and-interactions]: #examples-and-interactions Having laid out the plan, let us now return to how the current situation is characterized and see if the various facts that the factions orient themselves are respected. + +### Layering principles + +Some examples of ways t principles are upheld: + +- It is possible to use store without Nix lang + - (**publicity**, **compositionality**) + - Need `nix add-derivation` or similar to make this true! + +- It possible to use other languages with the store + - (**compositionality**) + - Guix able to use Nix daemon is a possible way to demonstrate this is true. +- It is possible to use the Nix language without Flakes + - (**compositionality**) + - True already +- It is possible to use pure eval without flakes + - (**gravity**, because "pure eval" is a feature not a layer) + - 95% true, but some "last mile" functionality is needed to make this "ergonomic enough for people to beleive it" + +Also, because public aspects of Nix are subject to a (nebulous) stability promise, exposing layering publically necessarily means stabilizing aspects of that layering too. +The precise details are not formally worked about, but one example would be: + + - We shouldn't collapse layers that were distinct such that people that are using the former lower layer in isolation are suddenly forced to "pay" for something they aren't using (the former upper layer). + ## Flakes are very popular And they will be stabilized, with minimal delay. @@ -222,7 +312,7 @@ The hope is that such scaffolding will assuage this faction their concerns are h # Drawbacks [drawbacks]: #drawbacks -The main downside is a small delay from the splitting Nix process, and then delay between the stabilization steps. +The main downside is a delay from the splitting Nix process, and then a delay between the stabilization steps. The fact that [RFC 134] is already mostly implemented, and in code review, is hopefully reason enough to believe it shouldn't take much longer. That maximum delay waiting for that to complete should be dwarfed by duration of time we've spent "in limbo" without a clear plan to move forward. @@ -240,7 +330,7 @@ As long as we are making progress stabilizing features and having healthy discus We could, of course, just "rip off the band-aid" and stabilize everything at once. The argument for that would be that enough time has passed and the concerns of (less numerous) long-time users are not important. -But we think the plan here has little downsides; we can instead make everyone happy with only a small delay. +But we think the plan here has little downsides; we can instead make everyone happy with only some delay. If that is true, why not do that instead! # Unresolved questions @@ -253,4 +343,6 @@ None at this time. Generalization features to work without Flakes, like pure eval and search, might be desired by the Flake-skeptic faction, but is purposely left as future work in order to not delay stabilization. +General feature stability lifecycle: https://discourse.nixos.org/t/potential-rfc-idea-stability/27055 + [RFC 134]: ./0134-nix-store-layer.md From e4ffc95cb0b567f96417b5020bacf88388ebbcc7 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Thu, 13 Apr 2023 15:23:40 -0400 Subject: [PATCH 27/35] 136: Reword first sentence --- rfcs/0136-stabilize-incrementally.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0136-stabilize-incrementally.md b/rfcs/0136-stabilize-incrementally.md index b6c7065e0..2821ebef0 100644 --- a/rfcs/0136-stabilize-incrementally.md +++ b/rfcs/0136-stabilize-incrementally.md @@ -11,7 +11,7 @@ related-issues: (will contain links to implementation PRs) # Summary [summary]: #summary -Stabilize the new command line interface and Flakes in an incremental fashion, leveraging [RFC 134]. +Decide how to stabilize the new command line interface and Flakes: in an incremental fashion, leveraging [RFC 134]. This plan is designed to still efficiently end the current "limbo" era of these unstable yet widely-used features, yet also soothe the longstanding tensions in the Nix community over how we got here. # Motivation From b51ed1536cc5bda5ebc06e44b75686dbfeb527f3 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Thu, 13 Apr 2023 16:23:47 -0400 Subject: [PATCH 28/35] More collaborative drafting --- rfcs/0136-stabilize-incrementally.md | 89 ++++++++++++++-------------- 1 file changed, 44 insertions(+), 45 deletions(-) diff --git a/rfcs/0136-stabilize-incrementally.md b/rfcs/0136-stabilize-incrementally.md index 2821ebef0..df07549f0 100644 --- a/rfcs/0136-stabilize-incrementally.md +++ b/rfcs/0136-stabilize-incrementally.md @@ -83,73 +83,55 @@ This "dusty corner" of the new CLI is rather calm with a very constrained design ## Conclusion -By starting with this relatively easy material to stabilize, we can prove we can all come together as a community to agree on a design after all. +By starting with this relatively easy material to stabilize (The CLI, in waves), we can prove we can all come together as a community to agree on a design after all. This should build trust between opposing individuals and factions, giving us a foundation upon which to tackle the more challenging material in subsequent steps. -Since these features became very popular while they are still unstable, there is now both an urgency to stabilize them, and little ability to modify them. -This is the opposite of how experimental features are supposed to leisurely incubate with both plenty of flexibility to change them, and little rush to stabilize them until they feel ready. -But, there is little we can do about this at this point, an this RFC recognizes that fact and does *not* try to resist it. - -But, we have crossed that Rubicon and there is no turning back; this RFC *doesn't* attempt to change Flakes or the command line. +We recognize that Flakes is widely used and will take precautions to ensure users are reasonably informed of any breaking changes that might occur from the stabilization. # Detailed design [design]: #detailed-design -> TODO out of date summary - -~~First we describe how stabilization should work in general. -Then we describe the order in which things are stabilized. -Finally we combine both into a list of step.~~ +While we could just move along and stabilize flakes bit-by-bit, in order to ensure a good Nix architecture now and for the future we start by establishing principles Nix should be guided by. +These principles should prevent similar problems from happening in the future and give us a target to strive for with the existing Nix. -This RFC consists of these parts: -- Establishing basic layering principles -- Define the different layers of Nix -- Make Nix conform to these layers - -## Layering principles +The detailed design of this RFC consists of these parts: -These basic layering principles will be added to the [Nix architecture documentation](https://nixos.org/manual/nix/stable/architecture/architecture.html): +- Establishing Principles + - Basic layering principles -- **Public-ity** + - Basic stabilization process principles - Layers are not just an implementation detail, instead they are publically exposed to the user via stable interfaces - - All exposed interfaces in Nix, both for computers or humans, must be matched to layers - - TODO: Move these to a stability section - - These exposed interfaces must conform to stability guarantees - - Functionality of layers must be either be stable or be marked as experimental, in which case breaking changes may happen - - The user has the option (it need not be mandatory!) to be aware of the layering and use it to learn Nix - - Both perspectives are equally valid, and neither is prioritized over the other - - While not going so far as to *insist* users are aware of layering and care about it, the layered archicture of Nix should be exposed to anyone that cares, and it shouldn't suddenly dissapear (as a mere implementation detail might). +- Plan brining Nix into compliance with the principles, and specifying the order the outstanding unstable CLI and Flakes features will be tackled. -- **Clarity of purpose** +## Layering principles - layers should not be too thick. - layers should "do one thing, and do it well". +These basic layering principles will be added to the [Nix architecture documentation](https://nixos.org/manual/nix/stable/architecture/architecture.html): -- **Modularity** +### For Nix as as a whole - One can replace the implementation of the layer with a different one, while using the same implemenations of any layers above and below. +- **Public Interfaces** - This is desirable but not currently required. E.g.: + Layers are not just an implementation detail, instead they are publically exposed to the user via stable interfaces + All exposed interfaces in Nix, both for computers or humans, must be matched to layers - - There does exist multiple stores, that should continue to work (and work better than it does today) - - We don't care about being able to swap out the evaluator in C++ Nix, however we *do* care that the language is defined well enough that other implementation of the Nix language is possible. +### For each layer -- **Gravity** +- **Clarity of purpose** - features should be in the lowest layer it makes sense to have them + Layers should not be too "thick". + Layers should "do one thing, and do it well". - **Compositionality** - layers should stand the alone: + Layers should stand alone: + - They should work as the top layer - - They should work expose a clear interface so it is possible to build multiple possible layers on top. + - They should also work *not* as the top layer, and with multiple possible layers above them + - They should expose a clear interface, which is what makes the previous point possible. -### Implementation +- **Gravity** -Nix currently marks experimental features in a formal way, which is excellent. -Nix should likewise mark deprecated features in a formal way. -It is good to be able to disable deprecated features before they removed to *prepare* for future breaking changes. + Features should be in the lowest layer it makes sense to have them. ## The general stabilization process --- audit, refine, and *then* stabilze @@ -196,7 +178,10 @@ The rounds thus look like this: 1. "installable"-free Store-only CLI 2. Rest of the Store-only CLI (includes "derived path" installables) 3. Rest of the flake-agnostic CLI + 2. Flakes + - Define the different layers of Nix? + - Make Nix conform to these layers? ## Combined plan @@ -265,9 +250,17 @@ It is OK to stabilize features that violate the layering principles, *only* so l Having laid out the plan, let us now return to how the current situation is characterized and see if the various facts that the factions orient themselves are respected. -### Layering principles +## Layering principles + +Rammifications to the user experience from layering being public: + + - The user has the option (it need not be mandatory!) to be aware of the layering and use it to learn Nix + + - Both perspectives are equally valid, and neither is prioritized over the other + + - While not going so far as to *insist* users are aware of layering and care about it, the layered archicture of Nix should be exposed to anyone that cares, and it shouldn't suddenly dissapear (as a mere implementation detail might). -Some examples of ways t principles are upheld: +Some examples of ways the principles are upheld: - It is possible to use store without Nix lang - (**publicity**, **compositionality**) @@ -288,6 +281,12 @@ The precise details are not formally worked about, but one example would be: - We shouldn't collapse layers that were distinct such that people that are using the former lower layer in isolation are suddenly forced to "pay" for something they aren't using (the former upper layer). +In the future, we might build atop this principles for a deeper notion of modularity: one should be able to replace the implementation of the layer with a different one, while using the same implementations of any layers above and below. +This is desirable but not currently required. E.g.: + + - There does exist multiple stores, that should continue to work (and work better than it does today) + - We don't care about being able to swap out the evaluator in C++ Nix, however we *do* care that the language is defined well enough that other implementation of the Nix language is possible. + ## Flakes are very popular And they will be stabilized, with minimal delay. From 4e252384807b364712ead4bee6c2a64f732d42d9 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Thu, 20 Apr 2023 16:00:13 -0400 Subject: [PATCH 29/35] Update summary --- rfcs/0136-stabilize-incrementally.md | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/rfcs/0136-stabilize-incrementally.md b/rfcs/0136-stabilize-incrementally.md index df07549f0..6501583c0 100644 --- a/rfcs/0136-stabilize-incrementally.md +++ b/rfcs/0136-stabilize-incrementally.md @@ -11,8 +11,19 @@ related-issues: (will contain links to implementation PRs) # Summary [summary]: #summary -Decide how to stabilize the new command line interface and Flakes: in an incremental fashion, leveraging [RFC 134]. -This plan is designed to still efficiently end the current "limbo" era of these unstable yet widely-used features, yet also soothe the longstanding tensions in the Nix community over how we got here. +Ever since the closing of [RFC 49](https://github.com/NixOS/rfcs/pull/49), we've had the new CLI and Flakes marked as experimental, with no clear plan forward. + +With the goal of ending this current limbo and soothe longstanding tensions in the Nix community, this RFC does two things: + +1. Establish general principles about Nix's architecture and evolution in order to ensure we do not get in this situation again. + + Notably we are allowed to make breaking changes to experimental features, which includes both the new CLI and Flakes, until they are stable. + +2. Establish an incremental plan adhering to the principles deciding on the order and priority in which to stabilize these features: + + - First, the non-Flakes CLI wll be stabilized, in phases. + + - Afterwards, Flakes itself and its CLI components can be stabilized. The final design of Flakes will also require another RFC. # Motivation [motivation]: #motivation @@ -292,7 +303,7 @@ This is desirable but not currently required. E.g.: And they will be stabilized, with minimal delay. Firstly, there is no feature work proposed in the interim --- the splitting of Nix is just partitioning existing functionality, with some behind-the-scenes refactors needed to make that possible. -The earlier steps have been carefully designed to be either easier or already started ("de-risked") to assuagee those that are concerned about the current "limbo" that stabilization will be gotten to no matter what, even if the splitting fails. +The earlier steps have been carefully designed to be either easier or already started ("de-risked") to do our best to convince those that are concerned about the current "limbo" that stabilization will be gotten to no matter what, even if the splitting fails. ## Difficulties in the roll-out From fb8458e02302240b4da2382b55ec7ef326e7d52a Mon Sep 17 00:00:00 2001 From: John Ericson Date: Wed, 10 May 2023 17:10:53 -0400 Subject: [PATCH 30/35] More updates from collaborative editing in meeting --- rfcs/0136-stabilize-incrementally.md | 50 ++++++++++++++++++---------- 1 file changed, 33 insertions(+), 17 deletions(-) diff --git a/rfcs/0136-stabilize-incrementally.md b/rfcs/0136-stabilize-incrementally.md index 6501583c0..83efd7054 100644 --- a/rfcs/0136-stabilize-incrementally.md +++ b/rfcs/0136-stabilize-incrementally.md @@ -21,18 +21,13 @@ With the goal of ending this current limbo and soothe longstanding tensions in t 2. Establish an incremental plan adhering to the principles deciding on the order and priority in which to stabilize these features: - - First, the non-Flakes CLI wll be stabilized, in phases. + - First, the non-Flakes CLI will be stabilized, in phases corresponding to Nix's architecture. - Afterwards, Flakes itself and its CLI components can be stabilized. The final design of Flakes will also require another RFC. -# Motivation -[motivation]: #motivation +# Problem statement +[problem-statement]: #problem-statement -Rewrite: -Nix currently has a somewhat layered interface, but this is a mere implementation detail. -Users of Nix could easily never know this. - -Old: For the past few years, we've accumulated a massive backlog of unstable features in the form of the new command-line interface and flakes. There is now a growing desire to stabilize those features, but as of yet no plan on exactly how to do so. The tension between that desire and a lack of a clear plan has loomed over our heads for a while; this RFC aims to dispel it by providing a concrete plan, an plan that hopefully will mitigate the lingering controversies and tensions around Flakes. @@ -69,6 +64,8 @@ But without the ability to populate some sort of initial list of store paths tha This is especially noticeable for new CLI features that *previously did*, in fact, work without Flakes. For example, in earlier versions of Nix, `nix search` worked without Flakes. +# High-level design + ## A plan all sides can be happy with Stabilizing the new CLI and Flakes will end the saga of the past few years. @@ -92,6 +89,25 @@ The CLI is more broadly popular, but still is a lot of material to discuss. The store-only subcommands are Nix's "plumbing" as opposed to "porcelain" commands, and thus have the simplest (if not most user-friendly) purposes. This "dusty corner" of the new CLI is rather calm with a very constrained design space, and far less acrimony. +## A plan so we don't get in this situation again + +We could just make up a plan for the CLI and Flakes --- everything discussed so far. +But that begs the question, where is that plan coming from? +Is it is ad-hoc reasoning just for this case, or following from some larger principles? + +We want to get out of the current situation, but we also want to make sure that we don't get in this situation again. +So this RFC also tries to come up with a set of larger principles that are meant to "show where the current plan is coming from", and and also set up ways of working so that these issues shouldn't arrive again. + +The more narrow of these principles is about how experimental features are developed and stabilized. +This hopefully is fairly uncontroversial and dovetails with the [experimental feature lifecycle documentation](https://nixos.org/manual/nix/stable/contributing/experimental-features.html) that was recently added to Nix. + +The broader of these principles is about Nix's architecture and a renewed commitment to layering. +It is the opinion of the author and shepherds (?) that lying behind some process woes is architectural uncertainty +--- Flakes being relatively big and addressing many things at once made it a somewhat unavoidable magnet for controversy even if the process we wanted was perfectly followed. + +Together this gives us a good "defense in depth": +we enshrine a process which should keep tensions down, and we seek to avoid features/behavior which would tempt us by its scope to veer from that process the first place. + ## Conclusion By starting with this relatively easy material to stabilize (The CLI, in waves), we can prove we can all come together as a community to agree on a design after all. @@ -102,9 +118,6 @@ We recognize that Flakes is widely used and will take precautions to ensure user # Detailed design [design]: #detailed-design -While we could just move along and stabilize flakes bit-by-bit, in order to ensure a good Nix architecture now and for the future we start by establishing principles Nix should be guided by. -These principles should prevent similar problems from happening in the future and give us a target to strive for with the existing Nix. - The detailed design of this RFC consists of these parts: - Establishing Principles @@ -112,7 +125,7 @@ The detailed design of this RFC consists of these parts: - Basic stabilization process principles -- Plan brining Nix into compliance with the principles, and specifying the order the outstanding unstable CLI and Flakes features will be tackled. +- Plan bringing Nix into compliance with the principles, and specifying the order the outstanding unstable CLI and Flakes features will be tackled. ## Layering principles @@ -146,10 +159,14 @@ These basic layering principles will be added to the [Nix architecture documenta ## The general stabilization process --- audit, refine, and *then* stabilze -Stabilization is not a matter of just flipping a switch on an implementation that has accrued for a period of time. +See the [current documentation on experimental features and their lifecyle](https://nixos.org/manual/nix/stable/contributing/experimental-features.html). + +**TODO perhaps cut this down to be more of a diff against the above, rather than redundant in many ways.8** + +Stabilization of any feature, not just the CLI or Flakes, is not a matter of just flipping a switch on an implementation that has accrued for a period of time. Because the moment before stabilization is our last chance to make major changes, it is crucial that we look over what is being stabilized. -To stabilize a piece of function we must do these things: +To stabilize a piece of functionality we must do these things: 1. **Audit the functionality** @@ -166,9 +183,9 @@ To stabilize a piece of function we must do these things: Note that for large, complex, and controversial features, an RFC is also required (per usual) to advance to the next step. The acceptance of the RFC concludes the "propose refinements" step. -3. **Create a "release candidate"** +3. **Ensure the candidate feature to be stabilized is just under one flag** - It should be possible to enable just the experimental that is ready for stabilization *in isolation*, without also enabling other unstable functionality. + It should be possible to enable just the experimental that is ready for stabilization *in isolation*, without also enabling other unstable functionality that is not ready for stabilization. This is important to allow users (and tests!) to try it out and make sure it is a meaningful feature in its own right, and not just a partially-complete things that relies on the further unstable features. If we have an RFC, the release candidate experimental feature should match the RFC. @@ -260,7 +277,6 @@ It is OK to stabilize features that violate the layering principles, *only* so l Having laid out the plan, let us now return to how the current situation is characterized and see if the various facts that the factions orient themselves are respected. - ## Layering principles Rammifications to the user experience from layering being public: From 6dc6a3030679614f1f677ef1dfd765c58df493a0 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Thu, 22 Jun 2023 16:56:39 -0400 Subject: [PATCH 31/35] Typos, sort of address TODO --- rfcs/0136-stabilize-incrementally.md | 55 +++++++++++++++++----------- 1 file changed, 34 insertions(+), 21 deletions(-) diff --git a/rfcs/0136-stabilize-incrementally.md b/rfcs/0136-stabilize-incrementally.md index 83efd7054..ad1491db7 100644 --- a/rfcs/0136-stabilize-incrementally.md +++ b/rfcs/0136-stabilize-incrementally.md @@ -43,7 +43,8 @@ As measured in the community polls, Nix has a lot of new users, dwarfing the num Flakes is very popular among these new users. Ergo, Flakes is very popular among the Nix community as a whole. -Many Groups and individuals interested in the continued growth the Nix community see Flakes are popular, an also wish it to be stabilized to attract still more users, since Flakes are already proven to be popular among users. +Many groups and individuals interested in the continued growth the Nix community see that Flakes are popular, and wish for them to be stabilized to attract still more users/ +The thinking is that if unstable Flakes are already proven to be popular, stable Flakes will be even moreso. ### Difficulties in the roll-out @@ -57,9 +58,9 @@ Experimental features are expected to be subject to community feedback, modified ### Flakes are criticized for encroaching on other features There are many criticisms about Flakes. -But one of them especially relevant to stabilizing is a perception that Flakes have encroached on other new features, in the sense that it ought to be possible to use them without Flakes but isn't in practice. -For example, there is no reason in theory that pure evaluation if Nix expressions requires Flakes. -But without the ability to populate some sort of initial list of store paths that are safe to import, pure evaluation in practice does require Flakes. +But one of them especially relevant to stabilizing is a perception that Flakes have encroached on other new features, in the sense that it ought to be possible to use those other features without Flakes but isn't in practice. +For example, there is no reason in theory that pure evaluation of Nix expressions requires Flakes. +But without the ability to populate some sort of initial list of store paths that are safe to import, pure evaluation does in practice require Flakes. This is especially noticeable for new CLI features that *previously did*, in fact, work without Flakes. For example, in earlier versions of Nix, `nix search` worked without Flakes. @@ -103,10 +104,10 @@ This hopefully is fairly uncontroversial and dovetails with the [experimental fe The broader of these principles is about Nix's architecture and a renewed commitment to layering. It is the opinion of the author and shepherds (?) that lying behind some process woes is architectural uncertainty ---- Flakes being relatively big and addressing many things at once made it a somewhat unavoidable magnet for controversy even if the process we wanted was perfectly followed. +--- Flakes being relatively big and addressing many things at once made it a somewhat unavoidable magnet for controversy, even had the process we now propose been perfectly followed. Together this gives us a good "defense in depth": -we enshrine a process which should keep tensions down, and we seek to avoid features/behavior which would tempt us by its scope to veer from that process the first place. +we enshrine a process which should keep tensions down, and we seek to avoid features/behaviors which would tempt us by their scope to veer from that process the first place. ## Conclusion @@ -161,38 +162,50 @@ These basic layering principles will be added to the [Nix architecture documenta See the [current documentation on experimental features and their lifecyle](https://nixos.org/manual/nix/stable/contributing/experimental-features.html). -**TODO perhaps cut this down to be more of a diff against the above, rather than redundant in many ways.8** - Stabilization of any feature, not just the CLI or Flakes, is not a matter of just flipping a switch on an implementation that has accrued for a period of time. Because the moment before stabilization is our last chance to make major changes, it is crucial that we look over what is being stabilized. -To stabilize a piece of functionality we must do these things: +To stabilize a piece of functionality (experimental -> stable in flowchart in linked documentation) we must do these things: 1. **Audit the functionality** Making note of the current state. Do this publicly so the Nix community writ large has a chance to weigh in. - The features to be stabilized should "stand alone", meaning that they should make sense and work both with and without further unstable features not yet undergoing the stabilization process. + Checklist during audit: -2. **Propose refinements of the functionality** + - **Documentation** - It is reasonable to notice things that were not noticed before the audit. - Features can either be changed, or they can be carefully carved out as ineligible for stabilization at this time, and left to be dealt with in a later round of this process. + Ideally the feature is already well-documented and the audit brings up nothing new. + But if it isn't, it must be by the end of the audit. - Note that for large, complex, and controversial features, an RFC is also required (per usual) to advance to the next step. - The acceptance of the RFC concludes the "propose refinements" step. + - **Whole feature flag, not part of a feature flag** + + It should be possible to enable just the experimental that is ready for stabilization *in isolation*, without also enabling other unstable functionality that is not ready for stabilization. + We are not allowed to propose to stabilize part of an experimenal feature and do so immediately. + We have to first break out the candidate functionality to be stabilized so it is just guarded by one feature flag. + + - **Self-Containment** -3. **Ensure the candidate feature to be stabilized is just under one flag** + With the previous checklist item ensuring that the feature *exists* in isolation, we then have to make sure it *make sense* in isolation. + The feature to be stabilized should "stand alone", meaning that it should make sense and work both with and without further unstable features not yet undergoing the stabilization process. - It should be possible to enable just the experimental that is ready for stabilization *in isolation*, without also enabling other unstable functionality that is not ready for stabilization. - This is important to allow users (and tests!) to try it out and make sure it is a meaningful feature in its own right, and not just a partially-complete things that relies on the further unstable features. + - **RFC Compliance** - If we have an RFC, the release candidate experimental feature should match the RFC. + If we have an RFC, the release candidate experimental feature should match the RFC. + +2. **Hold "Final Comment Period" for refinements of the functionality** + + It is reasonable to notice things that were not noticed before the audit. + Features can either be changed, or they can be carefully carved out as ineligible for stabilization at this time, and left to be dealt with in a later round of this process. + + Note that for large, complex, and controversial features, an RFC is also required (per usual) to advance to the next step. + The auditing and FCP for the feature in this case take place under the auspices of the RFC process. -4. **Actually stabilize** +3. **Actually stabilize** Only this last step is "stabilization proper". + This should be nothing more than removing a feature flag that has made it though the previous steps. ## CLI in waves, then Flakes @@ -215,7 +228,7 @@ The rounds thus look like this: Step 1 is technical work, with a self-imposed deadline so we can be sure it doesn't delay stabilization too long. The remaining steps are stabilization steps. -For each of them, a separate RFC or other discussion medium will describe the new interfaces to be stabilized, and solicit feedback. +For each of them, separate RFCs or other discussion media will describe the new interfaces to be stabilized, and solicit feedback. ### Step 0: Audit, refine, and stabilize the store-only installable-free CLI From 3a942d948534ef06324f4467e73be6650a086ddc Mon Sep 17 00:00:00 2001 From: John Ericson Date: Wed, 28 Jun 2023 22:36:47 -0400 Subject: [PATCH 32/35] Fix numerious typos and small issues Thanks so much! Co-authored-by: Valentin Gagarin Co-authored-by: Felix Uhl --- rfcs/0136-stabilize-incrementally.md | 35 ++++++++++++++-------------- 1 file changed, 17 insertions(+), 18 deletions(-) diff --git a/rfcs/0136-stabilize-incrementally.md b/rfcs/0136-stabilize-incrementally.md index ad1491db7..3f837a4d1 100644 --- a/rfcs/0136-stabilize-incrementally.md +++ b/rfcs/0136-stabilize-incrementally.md @@ -30,7 +30,7 @@ With the goal of ending this current limbo and soothe longstanding tensions in t For the past few years, we've accumulated a massive backlog of unstable features in the form of the new command-line interface and flakes. There is now a growing desire to stabilize those features, but as of yet no plan on exactly how to do so. -The tension between that desire and a lack of a clear plan has loomed over our heads for a while; this RFC aims to dispel it by providing a concrete plan, an plan that hopefully will mitigate the lingering controversies and tensions around Flakes. +The tension between that desire and a lack of a clear plan has loomed over our heads for a while; this RFC aims to dispel it by providing a concrete plan, a plan that hopefully will mitigate the lingering controversies and tensions around Flakes. ## The situation so far @@ -43,7 +43,7 @@ As measured in the community polls, Nix has a lot of new users, dwarfing the num Flakes is very popular among these new users. Ergo, Flakes is very popular among the Nix community as a whole. -Many groups and individuals interested in the continued growth the Nix community see that Flakes are popular, and wish for them to be stabilized to attract still more users/ +Many groups and individuals interested in the continued growth of the Nix community see that Flakes are popular, and wish for them to be stabilized to attract still more users. The thinking is that if unstable Flakes are already proven to be popular, stable Flakes will be even moreso. ### Difficulties in the roll-out @@ -94,7 +94,7 @@ This "dusty corner" of the new CLI is rather calm with a very constrained design We could just make up a plan for the CLI and Flakes --- everything discussed so far. But that begs the question, where is that plan coming from? -Is it is ad-hoc reasoning just for this case, or following from some larger principles? +Is it ad-hoc reasoning just for this case, or following from some larger principles? We want to get out of the current situation, but we also want to make sure that we don't get in this situation again. So this RFC also tries to come up with a set of larger principles that are meant to "show where the current plan is coming from", and and also set up ways of working so that these issues shouldn't arrive again. @@ -103,7 +103,7 @@ The more narrow of these principles is about how experimental features are devel This hopefully is fairly uncontroversial and dovetails with the [experimental feature lifecycle documentation](https://nixos.org/manual/nix/stable/contributing/experimental-features.html) that was recently added to Nix. The broader of these principles is about Nix's architecture and a renewed commitment to layering. -It is the opinion of the author and shepherds (?) that lying behind some process woes is architectural uncertainty +It is the opinion of the author and shepherds that lying behind some process woes is architectural uncertainty. --- Flakes being relatively big and addressing many things at once made it a somewhat unavoidable magnet for controversy, even had the process we now propose been perfectly followed. Together this gives us a good "defense in depth": @@ -111,7 +111,7 @@ we enshrine a process which should keep tensions down, and we seek to avoid feat ## Conclusion -By starting with this relatively easy material to stabilize (The CLI, in waves), we can prove we can all come together as a community to agree on a design after all. +By starting with the relatively easy target of stabilizing the CLI incrementally, we can prove we can all come together as a community to agree on a design after all. This should build trust between opposing individuals and factions, giving us a foundation upon which to tackle the more challenging material in subsequent steps. We recognize that Flakes is widely used and will take precautions to ensure users are reasonably informed of any breaking changes that might occur from the stabilization. @@ -122,11 +122,10 @@ We recognize that Flakes is widely used and will take precautions to ensure user The detailed design of this RFC consists of these parts: - Establishing Principles - - Basic layering principles + - Layering principles + - Stabilization process - - Basic stabilization process principles - -- Plan bringing Nix into compliance with the principles, and specifying the order the outstanding unstable CLI and Flakes features will be tackled. +- Plan bringing Nix into compliance with the principles, and specifying the order in which the outstanding unstable CLI and Flakes features will be tackled. ## Layering principles @@ -169,8 +168,8 @@ To stabilize a piece of functionality (experimental -> stable in flowchart in li 1. **Audit the functionality** - Making note of the current state. - Do this publicly so the Nix community writ large has a chance to weigh in. + Make note of the current state. + Do this publicly so the Nix community at large has a chance to weigh in. Checklist during audit: @@ -264,7 +263,7 @@ Whether or not it is possible to actually do this is left to the Nix Team to dec ### Step 4: Audit, refine, and stabilize the store-and-language-only Nix CLI -This is the rest off the new CLI, without Flakes. +This is the rest of the new CLI, without Flakes. Unlike the store-only Nix command which has yet to be implemented, this is easy to visualize today by enabling the `nix-command` feature without the `flakes` feature. This is a chance to discuss topics like: @@ -292,7 +291,7 @@ Having laid out the plan, let us now return to how the current situation is char ## Layering principles -Rammifications to the user experience from layering being public: +Ramifications to the user experience from layering being public: - The user has the option (it need not be mandatory!) to be aware of the layering and use it to learn Nix @@ -302,7 +301,7 @@ Rammifications to the user experience from layering being public: Some examples of ways the principles are upheld: -- It is possible to use store without Nix lang +- It is possible to use the Nix store without the Nix language - (**publicity**, **compositionality**) - Need `nix add-derivation` or similar to make this true! @@ -324,7 +323,7 @@ The precise details are not formally worked about, but one example would be: In the future, we might build atop this principles for a deeper notion of modularity: one should be able to replace the implementation of the layer with a different one, while using the same implementations of any layers above and below. This is desirable but not currently required. E.g.: - - There does exist multiple stores, that should continue to work (and work better than it does today) + - There do exist multiple stores, that should continue to work (and work better than it does today) - We don't care about being able to swap out the evaluator in C++ Nix, however we *do* care that the language is defined well enough that other implementation of the Nix language is possible. ## Flakes are very popular @@ -351,15 +350,15 @@ The hope is that such scaffolding will assuage this faction their concerns are h # Drawbacks [drawbacks]: #drawbacks -The main downside is a delay from the splitting Nix process, and then a delay between the stabilization steps. +The main downside is a delay from the process of splitting Nix up, and then a delay between the stabilization steps. The fact that [RFC 134] is already mostly implemented, and in code review, is hopefully reason enough to believe it shouldn't take much longer. That maximum delay waiting for that to complete should be dwarfed by duration of time we've spent "in limbo" without a clear plan to move forward. We therefore think that is a small and reasonable price to pay for the benefit of community harmony. -An addition, in the detailed design there is an escape hatch saying that blocking on the implementation of [RFC 134] can be reconsidered things do indeed take longer than foreseen. +An addition, in the detailed design there is an escape hatch saying that blocking on the implementation of [RFC 134] can be reconsidered if things do indeed take longer than foreseen. -The delay of "auditing and refining" and shouldn't represent time "idle" from a stabilization perspective. +The delay of "auditing and refining" shouldn't represent time "idle" from a stabilization perspective. As long as we are making progress stabilizing features and having healthy discussions, we don't see any problem. **Step 0** is also designed to take the pressure off these possible sources of delay, giving us *something* to work on that is not blocked on [RFC 134] or anything else. From 647ba9c894b41a643832900827f63f56c9c84586 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Fri, 14 Jul 2023 11:53:32 -0400 Subject: [PATCH 33/35] Remove last mention of a deadline The rest of these were already removed --- rfcs/0136-stabilize-incrementally.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0136-stabilize-incrementally.md b/rfcs/0136-stabilize-incrementally.md index 3f837a4d1..445f77d32 100644 --- a/rfcs/0136-stabilize-incrementally.md +++ b/rfcs/0136-stabilize-incrementally.md @@ -225,7 +225,7 @@ The rounds thus look like this: ## Combined plan -Step 1 is technical work, with a self-imposed deadline so we can be sure it doesn't delay stabilization too long. +Step 1 is technical work. The remaining steps are stabilization steps. For each of them, separate RFCs or other discussion media will describe the new interfaces to be stabilized, and solicit feedback. From 8e2b787e57adec125a8d44db72b5141dc9f4f9d0 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Wed, 9 Aug 2023 09:18:31 -0700 Subject: [PATCH 34/35] Fix typo Thanks! Co-authored-by: Ryan Lahfa --- rfcs/0136-stabilize-incrementally.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0136-stabilize-incrementally.md b/rfcs/0136-stabilize-incrementally.md index 445f77d32..e8972beca 100644 --- a/rfcs/0136-stabilize-incrementally.md +++ b/rfcs/0136-stabilize-incrementally.md @@ -313,7 +313,7 @@ Some examples of ways the principles are upheld: - True already - It is possible to use pure eval without flakes - (**gravity**, because "pure eval" is a feature not a layer) - - 95% true, but some "last mile" functionality is needed to make this "ergonomic enough for people to beleive it" + - 95% true, but some "last mile" functionality is needed to make this "ergonomic enough for people to believe it" Also, because public aspects of Nix are subject to a (nebulous) stability promise, exposing layering publically necessarily means stabilizing aspects of that layering too. The precise details are not formally worked about, but one example would be: From 64fe8f30d9b75b78f6dd81359b14f5ac95abce93 Mon Sep 17 00:00:00 2001 From: Tom Bereknyei Date: Sat, 12 Aug 2023 20:29:05 -0400 Subject: [PATCH 35/35] fix: minor fixes --- rfcs/0136-stabilize-incrementally.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rfcs/0136-stabilize-incrementally.md b/rfcs/0136-stabilize-incrementally.md index e8972beca..e626f80ee 100644 --- a/rfcs/0136-stabilize-incrementally.md +++ b/rfcs/0136-stabilize-incrementally.md @@ -180,7 +180,7 @@ To stabilize a piece of functionality (experimental -> stable in flowchart in li - **Whole feature flag, not part of a feature flag** - It should be possible to enable just the experimental that is ready for stabilization *in isolation*, without also enabling other unstable functionality that is not ready for stabilization. + It should be possible to enable just the experimental feature that is ready for stabilization *in isolation*, without also enabling other unstable functionality that is not ready for stabilization. We are not allowed to propose to stabilize part of an experimenal feature and do so immediately. We have to first break out the candidate functionality to be stabilized so it is just guarded by one feature flag. @@ -379,7 +379,7 @@ None at this time. # Future work [future]: #future-work -Generalization features to work without Flakes, like pure eval and search, might be desired by the Flake-skeptic faction, but is purposely left as future work in order to not delay stabilization. +Generalizing features (live pure eval and search) to work without Flakes might be desired by the Flake-skeptic faction, but is purposely left as future work in order to not delay stabilization. General feature stability lifecycle: https://discourse.nixos.org/t/potential-rfc-idea-stability/27055