-
-
Notifications
You must be signed in to change notification settings - Fork 158
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC 0136] A plan to stabilize the new CLI and Flakes incrementally #136
Changes from 8 commits
0a97c81
6a8dedc
ce46413
2f151ef
509e2f1
49abe39
4113118
1181c57
921ea84
2d26b8d
6e6ed87
1b9710c
ab194b1
5e13c23
c79cc3e
beaaf5a
09f1943
9a1ff22
abf0819
9ad0f90
4b32f7d
ce6cc82
53f4c69
509e1d1
e1b741b
ca44ef6
2ea03b3
e4ffc95
b51ed15
4e25238
fb8458e
6dc6a30
3a942d9
647ba9c
8e2b787
64fe8f3
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||||
---|---|---|---|---|---|---|---|---|
@@ -0,0 +1,199 @@ | ||||||||
--- | ||||||||
feature: stabilize-incrementally | ||||||||
start-date: 2022-09-15 | ||||||||
author: John Ericson | ||||||||
co-authors: (find a buddy later to help out with the RFC) | ||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is this still supposed to say “(find a buddy later to help out with the RFC)” even though it’s been merged? |
||||||||
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 | ||||||||
|
||||||||
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 | ||||||||
|
||||||||
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. | ||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This obscures the subject. Who has this growing desire? And why is it important? |
||||||||
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. | ||||||||
Ericson2314 marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||
|
||||||||
## 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 | ||||||||
Ericson2314 marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||
|
||||||||
### Flakes are very popular | ||||||||
|
||||||||
As measured in the community polls, Nix has a lot of new users, dwarfing the number of long-time users. | ||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would add a link to one or two of the polls. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. |
||||||||
Flakes is very popular among these new users. | ||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Here's some new off-site documentation where people assume a general audience and do their best to write quite good tutorials which both take flakes as a starting point. I'm coming in from these and I imagine lots more people given how popular both these people are. Switching from flakes to non-flakes Nix for me at this point is jarring. |
||||||||
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. | ||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is the crux of the issue, and I can't agree with it. Going into an effort to stabilise Flakes with the understanding that we can't actually change it very much would make a mockery of the RFC process as a whole. It would establish a precedent that following the RFC process is optional, and that if you don't want to follow it (and you're one of the privileged set of committers to the appropriate repository) you can work around it encouraging adoption of your "experimental" work until it gets to the point that "we can't make big changes" any more. Maybe the Flakes design is good enough that we wouldn't need to make huge drastic changes, but it still sets the same precedent if we go into it having accepted that we can't. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. One of the early breakages of the It's good that people are trying flakes because it provides feedback, but it seems pretty obvious to me that anything can be changed. There is no guarantee here. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The 1 year Nix roadmap the NixOS foundation is working on contains an ominous reference to “start thinking about Flakes 2.0.” This will hopefully be clarified until NixCon, but it seems like breaking Flakes (in some controlled way, presumably) is already on the cards. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think Flakes 2.0 may not necessary be new features. @alyssais I agree Flakes was advertised much more heavily than, say, Rust experimental features, which does make the whole process very dodgy. But I have also long since given up on trying to influence Flakes. @edolstra and others have a very specific vision on what UX they want for them, and I think a fine compromise is that they can basically do whatever they want with that so long as there remains a "rest of Nix" that is still fully functional and not an afterthought with huge gaps. In other words, I would personally work very hard to make sure the first two round of stabilizations under the plan yield a good result, making requests for some small tweak dyed-in-the-whole Flakers find baffling or boring. But then for the 3rd round, I would largely bow out, having gotten the things I wanted. Now, I am by no means demanding that persons besides myself do the same; there is still a 3rd round of stabilization for those interested in Flakes to voice their thoughts. But I gather a lot of the tensions around Flakes is predicated on a fear that Flakes will be the only way forward, with the non-Flakes functionality legacy stuff or otherwise left to rot. I think by making sure that the non-Flakes stuff is still good, or at least leaving room for that (e.g. we can rename There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would say that pushing flakes through an imitation RFC process without properly addressing the criticism would damage RFC process without really adding anything to flakes (hard to get extra credibility from the process that just lost its credibility). I guess with incremental stabilisation of Flakes we could reach a state where some things can neither be stabilised via an RFC nor removed via an RFC? I don't like this outcome too much, but maybe this would at least reduce the splash damage… (From experience, I am pessimistic about making consistent good decisions about issues, but somewhat optimistic about compartmentalising the damage) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @7c6f434c The common goal would be stabilizing the flakes-agnostic CLI. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Even there, I think some people want There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @alyssais I agree. Saying "flakes are widely used, so we can't break interfaces even if they're not declared stable" is flawed reasoning. @tomberek recently pointed out to me that leading figures have been encouraging users to adopt flakes since NixCon 2019. And it still happens in side channels all the time, new users being introduced with literally saying "it's fine, just enable experimental features, it's the right way to do things" or "it's strongly encouraged" – by whom? These are people's opinions, they are free to have them, and others are free to believe them, but the manual and the guards in the code clearly state: this interface is subject to change. Don't rely on experimental features in production, unless you know what you're doing and know how to get yourself out of a mess. There is no deadline on stabilising the new CLI or flakes, because we don't want to get stuck with what we may end up regretting. I'm not in the position to conclusively judge and not willing to opine whether the new CLI design or the flakes paradigm of organising Nix projects are the right way forward and whether the improvements in user experience are worth the sunk cost. But I'm confident with stating that the kind of signaling and narrative we have observed
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This sentence is now removed! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I won't even read non-flake tutorials I must say because it feels like the old way of doing things. I'd say, why not both? It's fine to point new people to flakes if that's easier to get them onboarded (which many people believe it is) and even then it's fine to massively break flakes in the future if you get the design right. |
||||||||
|
||||||||
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. | ||||||||
Ericson2314 marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||
|
||||||||
### 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. | ||||||||
Ericson2314 marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||
|
||||||||
### Flakes are criticized for encroaching on other features | ||||||||
Ericson2314 marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||
|
||||||||
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. | ||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
Ericson2314 marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||
|
||||||||
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 | ||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
Maybe a bit less ambitious? |
||||||||
|
||||||||
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. | ||||||||
Ericson2314 marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||
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. | ||||||||
Ericson2314 marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||
|
||||||||
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. | ||||||||
Ericson2314 marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||
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. | ||||||||
Ericson2314 marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||
|
||||||||
## 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. | ||||||||
Ericson2314 marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||
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. | ||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
See my other comment about flawed reasoning. Maybe this sentence should go away altogether. |
||||||||
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 | ||||||||
Ericson2314 marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||
|
||||||||
# Detailed design | ||||||||
[design]: #detailed-design | ||||||||
|
||||||||
Step 1 is technical work, with a self-imposed deadline so we can be sure it doesn't delay stabilization too long. | ||||||||
Ericson2314 marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||
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. | ||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is it in scope for the RFC to define the exact set of these commands (either by enumerating them, or by stating which property they need to have)? If not, where would this be done? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am not sure whether it is in-scope, but here is one such (WIP) list NixOS/nix#7701 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would say it is out-of-scope. This RFC lays out the intention and the process, and we have to align on that first. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Out of scope is better, thanks |
||||||||
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. | ||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Can we get a reference for this, or otherwise remove it? I don't think it adds any value to the argument as it is ;) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it might be in Nix team meeting notes which are yet to be posted? Could just drop it I suppose just want to give @roberth credit for the idea :). |
||||||||
|
||||||||
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. | ||||||||
|
||||||||
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. | ||||||||
Ericson2314 marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||
|
||||||||
## 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. | ||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Actually, even if store-only Nix is not there, can There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, but I worry we will accidentally mess things up without the rigorous correct-by-construction layering that building subsets of Nix gives us. Basically, in my opinion proven freedom from layer violations is a major way we can tell a "plumbing" command (to use the git term) is good. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Actually current RFC #134 does not seem to require that eval-part of Nix goes only through the CLI-exposed part of store-Nix, does it? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No it does not, but I meant making sure low level commands don't need high level library code. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. But this doesn't really prove that the store-Nix is useful as plumbing without layering violations (like the current way of specifying a specific output), does it? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh OK, I thought you were saying we needed a more stringent process, but it sounds like you are saying the opposite. Sure, that makes sense. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I want a more stringent process but I also admit we don't need it as a hard requirement! (And a more stringent process has more cost) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sure I agree. I am hoping I get that prev RFC approved / PR done regardless and it's a non-issue, but if I fail then yes it is good that we can still stabilize things incrementally. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @7c6f434c It seems you're on the same page now. Maybe you can mark the conversation as resolved? That would make it easier to see if there's still something left to discuss or not. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am not sure we were on the same page back then, but the situation has shifted enough to make the minor differences moot. … as of the literal question you ask — as far as I can see, I cannot. GitHub probably doesn't think reviewers should be able to resolve the points they raise. |
||||||||
|
||||||||
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 | ||||||||
Ericson2314 marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||
- 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. | ||||||||
Ericson2314 marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||
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. | ||||||||
Ericson2314 marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||
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? | ||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What does that mean? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Basically the |
||||||||
|
||||||||
## Step 4: Stabilize Flakes itself | ||||||||
|
||||||||
Finally, with the other less controversial interfaces stabilized, we can tackle the Flakes itself, the one remainder. | ||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is this thought of as an all-in-one thing (flake file format, registry, installables format, ..) or will we have seperate discussions on these topics? The old RFC covered a wide range of things (which wasn't great) so we might want to keep this in mind. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah I don't mean for this RFC to preclude further splitting up and incremental stabilizing, just obligate us to to at least try stabilizing these things first. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The PRs to address drv files In general I doubt we should cling to too many specifics because that won't age well. |
||||||||
|
||||||||
# 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. | ||||||||
|
||||||||
## Flakes are very popular | ||||||||
|
||||||||
And they will be stabilized, with minimal delay. | ||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Saying minimal makes it sound that it's somehow guaranteed to be bounded. I know what you mean, but it needs to strike the right tone. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe calling it a "high priority"? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What exactly is "minimal delay" supposed to mean and how is that ensured? Is that even desirable, let alone achievable, given all the plans to find a path of least controversy? |
||||||||
|
||||||||
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. | ||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is a crucial statement and possibly worth an RFC on its own in order for everyone to accept and digest that message. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Are we talking full feature freeze here or only functionality related to flakes? |
||||||||
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. | ||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What's this camp? |
||||||||
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. | ||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can you clarify what the "without Nix language support" subset of the new CLI is referring to? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The would be the store-only CLI. |
||||||||
|
||||||||
The hope is that such scaffolding will assuage this faction their concerns are heard without holding things up. | ||||||||
|
||||||||
# Drawbacks | ||||||||
[drawbacks]: #drawbacks | ||||||||
|
||||||||
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. | ||||||||
Ericson2314 marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||
|
||||||||
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. | ||||||||
Ericson2314 marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||
|
||||||||
**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 | ||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. More alternatives:
I expect a proposal with such a broad reach to thoroughly explore alternatives and dispassionately assess their benefits, downsides, and implementation costs. Not having that kind of overview right here frames the discussion to the particular perception of the authors (which is inevitable to begin with by nature of authorship, but can be at least alleviated by keeping the solution space in view). |
||||||||
[alternatives]: #alternatives | ||||||||
|
||||||||
We could, of course, just "rip off the band-aid" and stabilize everything at once. | ||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. One alternative could be to break flake under a new name or call this v1 and announce that v2 will have breaking changes. semver write
This could apply to the current usecase as it's what major versions are there for. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. How is that break supposed to be implemented? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I also disagree with that proposal. The transition from regular nix to flakes nix is not always easy and can't be done all at once. Being able to use the same store and switch back-and-forth between using flakes and not is critical to prevent splitting the userbase. However, I think this RFC opens the door to creating one or multiple experimental flake-based frontends based on the lower-level Nix Store and Nix Language. So you can still make breaking changes, but they are scoped and more experimentation is possible. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah the issue right now is not having multiple versions of Flakes, it's maintaining them. When there are not clear layer boundaries (bits of Flakes stuff all around If we do succeed in make Flakes a separate project (my dream, not proposed as part of this RFC as written). Then yes, now the maintainence cost is much better. Out-of-tree front-ends can do whatever they want! |
||||||||
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. | ||||||||
Ericson2314 marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||
If that is true, why not do that instead! | ||||||||
|
||||||||
# Unresolved questions | ||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Let me preface this with appreciation for the work the author/shepherd team did to get things written down. The following is not to dismiss any of that, to the contrary, and is aiming to follow the practice of RFCs piling up considerations in order to help converging on a reasonable solution design. Overall, I think the scope is too broad. There are many generally agreeable statements in there, but they tend to be vague and largely inconsequential. Regardless, I expect some of them to produce both some enlightening and some needless contention when scrutinized. I think this hasn't really happened yet, because the text is also still quite long for what it's trying to say, although it seems to have improved since the first versions. Going in some more detail, the broad technical strokes seem fine, but could be a lot more concrete – if there is even anything to debate about them, that would be uncovered by delving into the actual design questions. That of course begs the question if there should be more RFCs detailing individual aspects (which is what Graham suggested in the post referenced here) or if some of those issues can be addressed as PRs. Many proposed statements can be managed easily within the Nix maintainers team and merged into official documentation directly. Which brings me to the conceptual part: I understand this document is mainly about building trust and community consensus, but the problem statement and motivation is formulated only very weakly. What exactly is wrong with flakes not being stable? What exactly are the problems under discussion, and which trade-offs have to be considered for making a decision? Who are these "some people", and why does their opinion matter? To be precise, why is it that we can't just either remove the experimental flags xor remove the experimental feature itself? This would be important to state so readers can judge whether the problem is relevant and stated truthfully, whether the weighing of considerations is appropriate, and why the given conclusions are more reasonable than the alternatives. Finally, I'm missing a consideration of project objectives and resource constraints. For instance, we can't really talk about timing. So far we didn't even manage to talk about order of work done, although we did succeed at agreeing on some priorities, such as improving testing and fixing bugs. Also, who is supposed to implement the changes? And wouldn't the proposed steps be taken regardless of this discussion anyway? Do Nix maintainers really need to request for comments to go about changes incrementally, as they do already? And for far-reaching changes, where I think it would be sensible to open a broader discussion, where is the threshold and should we take on even more of those instead of finishing one thing first? Not addressing that would make this proposal, especially in light of its emphasis on popularity and people waiting for things, amount to saying "done when it's done, maybe never". Which would be absolutely no improvement over the current state of affairs. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've tried to formulate multiple answers to this comment because I felt it was quite a harsh take, but every time I tried to argue against it, I have to concede that you are correct. This RFC has already influenced discussions AFAICT, but the substance is so broad that it's questionable whether merging it would have any impact internally beyond that. It's still valuable as a document to show what the current challenges are, but merging it seems to be inconsequential. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think the basic issue is that when I started writing this, I felt like very much an outsider to Nix's development, and the ideas expressed in here felt like outsider/underdog ideas. Now, I am on the Nix Team (!), and there are some other like-minded people on the Nix team, and the most pro-Flakes people don't seem to be pouncing on this RFC keeping high pressure to compromise. If people don't show up to argue back, then yes it is tempting to revise this to be something a lot stiffer. E.g. my personal "dream" roadmap:
I guess I could go write that RFC. And yes, it would be a lot sharper. But I assume the vast majority of people here would be like "wtf is that I'm so confused?". I am I mistaken? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's tough, but I see what you mean. This is a good start. Having it codified would be a good checkpoint. There's nothing more for me to add. I think there are comments of me left, but after the recent changes I don't have anything more to say. I guess it's time for FCP? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Even if this RFC isn't great, it's not bad either, it definitely doesn't make things worse. I'd like accept this RFC as is just so we can move on and focus on more concrete efforts: #136 (review) |
||||||||
[unresolved]: #unresolved-questions | ||||||||
|
||||||||
How long should the deadline for creating the store-only Nix be? | ||||||||
|
||||||||
# 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. | ||||||||
tomberek marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||
|
||||||||
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While the motivation for this RFC is the stabilization of flakes, I do find the layering principles etc. good and important enough that they should be part of the RFC title. I'd like this RFC to state that those principles apply to the general Nix development, and are not only for the stabilization of Flakes effort.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not even find Flakes in the current state net-positive, but this RFC is an improvement even if Flakes did not exist, and also draws a good plan to make Flakes not do damage. So yes, something about layering for incremental stabilisation of features (including Flakes) would be a nice title.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The layering was developed and added explicitly to ensure there was a proper separation between concerns. Title can be better, but it seems the intention was communicated. Thanks!