[RFC 0157] More granular control over the system #157
Conversation
|
Could we have more granular control over this RFC? This seems like (at least) three separate RFCs that have been lumped together. |
Sure, the decoupling of nixos module is the major one here, that'll enhance the usage of nix in and outside NixOS, I'll try to split rest of them into separate RFC (or remove the parts unneeded, if any) |
|
@Animeshz Any progress on that btw? |
|
@nyabinary Sorry I've been really busy with other things, I've reduced the scope of the RFC as others pointed out, now to only aim at allowing to expose more fundamental parts of the system from modules, and make it more flexible to swap components in future. CC @amjoseph-nixpkgs @AndersonTorres @Ma27 @7c6f434c let me know if this shortened RFC scope is relevant or not :) Marking it open for review! |
|
|
||
| Decoupling the system from fixed parts can be done by availing configuration options under the NixOS modules: | ||
|
|
||
| ```nix |
There was a problem hiding this comment.
I have a feeling it needs a PoC. Maybe creating a small system from power up to bash prompt.
There was a problem hiding this comment.
@AndersonTorres I had started working on the PoC right away that day, although soon I realized it doesn't really relates much to this.
I believe a better idea would be to shrinking down
- the activation script (
rg 'activationScripts\.'on root of nixpkgs clone) - majorly the things that are unconditionally added to the activation script, without choosing any option, even on empty configs. - the main derivation's buildCommand that populates the nixos-rebuild output directory.
- and the etc derivation's buildCommand that populates etc/ subdirectory in the nixos-rebuild output directory.
behind a dedicated option for each of them in the configuration.
That will slowly create options, as well as allocate multiple choices for that options. This can also be slowly integrated into the nixpkgs, as we could do it first for bootloader, then for init, and so on in separate PRs, without touching everything at once.
Let me know what do you think, making things from groundup or shrinking down what's already in there. Because latter one looks much better to do.
|
This RFC is now open for shepherd nominations. |
kevincox
added
the
status: open for nominations
|
This RFC has not acquired enough shepherds. This typically shows lack of interest from the community. In order to progress a full shepherd team is required. Consider trying to raise interest by posting in Discourse, talking in Matrix or reaching out to people that you know. If not enough shepherds can be found in the next month we will close this RFC until we can find enough interested participants. The PR can be reopened at any time if more shepherd nominations are made. |
|
But how do you support multiple init/service supervisor without adding an abstraction layer? Requiring every service maintainer to write service configuration (that is already very low level btw) in a couple of other formats again and again? Or letting the users write services themselves? For other parts (boot method, libc, kernel and so on) the abstraction layer shouldn't be the blocking issue. The real problem is we lack people actively creating, maintaining and using different implementations with great interest. without a lot of continuous investment, these implementations will quickly become unusable. |
|
I'm interested in being a shepherd for this RFC. Hopefully some other interested parties will show up as well. |
|
I personally believe this RFC will hugely benefit from #163. |
Yes, since the generalization of service management is handled by that RFC in detail, it'll remove some unanswered questions about service creations and reduce a huge load on this. Also, on the #163 (comment),
If we eliminate the assumptions NixOS makes, about the system, a part of this RFC, the home-manager can also be easily merged into nixpkgs as nixos module itself (theoretically), and then nixos modules can be used inside/outside NixOS. |
Wouldn't including home-manaager into NixOS/nixpkgs include a lot of refactorings? |
Technically, the types in home-manager such as dag & gvariant may benefit nixpkgs modules. And regarding refactorings, yes, it might incur a few, but since home-manager is primarily focused on files on $HOME, I don't think there'd be a lot of overlap and hence easily integratable. If however, some package can be configured both ways (system and home level) then probably something has to be done to deduplicate and reduce the confusion among the config options. |
|
This RFC is being closed due to lack interest. If enough shepherds are found this issue can be reopened. If you don't have permission to reopen please open an issue for the NixOS RFC Steering Committee linking to this PR. |
Wasn't this party interested in being a shepherd? |
|
No one else expressed interest though, right? 1 person isn't enough. |
Summary
RFC proposes to grant more granular low-level control over the system (reduction of unnecessary abstractions). This may results in finer, transparent and more accessible setups.
Rendered