From 2e84b448aca02397ed528caaa63be7b906095294 Mon Sep 17 00:00:00 2001 From: Anderson Torres Date: Mon, 26 Aug 2024 21:17:21 -0300 Subject: [PATCH 01/14] RFC draft AYHMABTU --- rfcs/9999-assimilate-home-manager.md | 197 +++++++++++++++++++++++++++ 1 file changed, 197 insertions(+) create mode 100644 rfcs/9999-assimilate-home-manager.md diff --git a/rfcs/9999-assimilate-home-manager.md b/rfcs/9999-assimilate-home-manager.md new file mode 100644 index 000000000..3f26175dc --- /dev/null +++ b/rfcs/9999-assimilate-home-manager.md @@ -0,0 +1,197 @@ +- feature: All Your Home Manager Are Belong to Us +- start-date: (fill me in with today's date, YYYY-MM-DD)- +- author: Anderson Torres +- 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 + +Assimilate home-manager project into Nixpkgs monorepo. + +# Terminology +[terminology]: #terminology + +Henceforth, + +- Home Manager will be called _HM_; +- The typical unprivileged user of a system will be called _basic user_; +- The typical privileged user of a system will be called _superuser_; + +# Motivation +[motivation]: #motivation + +Nix the language has at least three large-size consumers, namely: + +- [Nixpkgs](https://github.com/NixOS/nixpkgs), the biggest packageset in + existence; +- [NixOS](https://nixos.org/), the reference work on declarative configuration + and deployment of a Linux distribution; and +- [Home Manager](https://nix-community.github.io/home-manager/), another + reference work on declarative user-specific configuration management and + deployment. + +Since at least 2014, NixOS was assimilated into Nixpkgs monorepo, now living +inside `nixos` directory. + +This RFC proposes a similar assimilation of Home Manager into Nixpkgs. + +## Benefits + +In principle, Nix already leverages Nixpkgs for basic users. However, the raw +usage of Nixpkgs is not too ergonomic, especially when compared to the more +structured model of NixOS. + +HM provides a similar centralized, modular, declarative package management +experience to basic users, without the need of granting them superuser +privileges. + +Given that NixOS - a system that leverages Nixpkgs for superusers - is already +bundled inside Nixpkgs tree, a fortiori HM - a system that leverages Nixpkgs for +basic users - should be included as the default, Nixpkgs-blessed system for +basic users. + +Further, this assimilation will benefit two interesting sets of people: + +01. Users of Nixpkgs and/or NixOS that are reluctant in using HM, since it is + neither official nor well-integrated into Nixpkgs workflow. + +01. Users of NixOS that already use HM in tandem, as a convenient way of + separating basic users' business from system administration tasks. + +Another great advantage of assimilating HM to Nixpkgs is a tighter integration +between both projects: + +01. Merging HM into Nixpkgs eliminates a barrier between both projects, + conveying more flexibility in code sharing, deduplication and refactoring in + general. + +01. Refactors, reformulations, deprecations and removals of packages and other + related functionalities are commonplace around Nixpkgs. Since HM is + dependent on Nixpkgs, it needs to monitor and synchronize such activities. + + The eventual assimilation proposed here drops those issues dramatically. + +01. The merge of communities brings a new point of view about package maintenace + in general. + + NixOS is the main point of structured conglomeration of packages; because of + this, Nixpkgs is arguably more inclined to favor a superuser view of system + administration. + + Bringing HM to Nixpkgs provides a new point of view, more akin to the basic + user. + +01. Making HM an official, blessed tool conveys more credibility to both + Nixpkgs and HM. + +# Detailed design +[design]: #detailed-design + +There are many possible approaches for this assimilation. Here I will propose a sketch: + + +01. Prepare HM to migration + + Currently Nixpkgs monorepo requires certain rules to accept code. + +01. Prepare Nixpkgs to migration too + + There is some expectation of preparing Nixpkgs to deal with the big input of + new code. A merge train will be useful here and in subsequent steps. + +01. Merge HM repository so that its files are kept in `home-manager` directory + +01. Polish the rough edges + +01. Profit! + +# Examples and Interactions +[examples-and-interactions]: #examples-and-interactions + +Ideally, after the assimilation, a basic user will experience few to no changes +in their workflow. The channels of distribution of both Nixpkgs and HM will be +merged, promoting a cleanup on setups that otherwise would need synchronization. + +On the other hand, from this assimilation forward the typical package maintainer +will interact with potentially two sets of too similar module systems. This +brings a momentum to deduplicate code and build abstractions, however this is +not in the scope of this RFC. + +# Drawbacks +[drawbacks]: #drawbacks + +The main drawback of this assimilation stem from the resulting complexity. + +## Standardization + +There are some discrepancies between the practices of both communities. How they +should be accomodated? + +## Synchronize the communities + +There are almost 660 contributors in HM to this date. How they should be +allocated? + +Ideally they should keep the same roles. + +## CI + +Currently HM uses its own setup for continuous integration. Ideally the Nixpkgs +setup should be updated to include HM's specific needs. + +# Alternatives +[alternatives]: #alternatives + +The alternatives are + +- The trivial "do nothing" + + It just exacerbates the status quo, bringing nothing in the long term. + +- Bless another home management tool + + HM is battle-tested and well renowned. There is no other tool remotely + comparable to it. + +- Build a home management tool from scratch + + This alternative dismisses the know-how accumulated by HM. An acceptable + middle ground would be to create some "library extension" to accomodate future + HM-like modules and use that extension to migrate HM modules. + +# Prior art +[prior-art]: #prior-art + +As an example of prior art, there is our Scheme-based cousin, Guix Software +Distribution. Since at least 2022 AD they bring a similar tool, conveniently +called Guix Home. + +The nicest thing about this tool is that it is tightly integrated with Guix, to +the point of `home` being a mere subcommand of `guix`. + +# Unresolved questions +[unresolved]: #unresolved-questions + +How the future package inclusions should be carried out? + +# Future work +[future]: #future-work + +- Update an extend the CI +- Set expectations on portability among present and future platforms Nixpkgs + supports + - Especially outside NixOS + - Especially outside Linux +- Factor HM and NixOS's shared code into some service abstraction structure + +# References +[references]: #references + +- [Keeping One's Home + Tidy](https://guix.gnu.org/en/blog/2022/keeping-ones-home-tidy/), by Ludovic + Courtès +- [Guix Home + Configuration](https://guix.gnu.org/manual/devel/en/html_node/Home-Configuration.html) From 7628248efc9406a23dc762e6f2946ad13a062d63 Mon Sep 17 00:00:00 2001 From: Anderson Torres Date: Fri, 13 Sep 2024 12:15:08 -0300 Subject: [PATCH 02/14] remove assimilation --- rfcs/9999-assimilate-home-manager.md | 197 --------------------------- 1 file changed, 197 deletions(-) delete mode 100644 rfcs/9999-assimilate-home-manager.md diff --git a/rfcs/9999-assimilate-home-manager.md b/rfcs/9999-assimilate-home-manager.md deleted file mode 100644 index 3f26175dc..000000000 --- a/rfcs/9999-assimilate-home-manager.md +++ /dev/null @@ -1,197 +0,0 @@ -- feature: All Your Home Manager Are Belong to Us -- start-date: (fill me in with today's date, YYYY-MM-DD)- -- author: Anderson Torres -- 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 - -Assimilate home-manager project into Nixpkgs monorepo. - -# Terminology -[terminology]: #terminology - -Henceforth, - -- Home Manager will be called _HM_; -- The typical unprivileged user of a system will be called _basic user_; -- The typical privileged user of a system will be called _superuser_; - -# Motivation -[motivation]: #motivation - -Nix the language has at least three large-size consumers, namely: - -- [Nixpkgs](https://github.com/NixOS/nixpkgs), the biggest packageset in - existence; -- [NixOS](https://nixos.org/), the reference work on declarative configuration - and deployment of a Linux distribution; and -- [Home Manager](https://nix-community.github.io/home-manager/), another - reference work on declarative user-specific configuration management and - deployment. - -Since at least 2014, NixOS was assimilated into Nixpkgs monorepo, now living -inside `nixos` directory. - -This RFC proposes a similar assimilation of Home Manager into Nixpkgs. - -## Benefits - -In principle, Nix already leverages Nixpkgs for basic users. However, the raw -usage of Nixpkgs is not too ergonomic, especially when compared to the more -structured model of NixOS. - -HM provides a similar centralized, modular, declarative package management -experience to basic users, without the need of granting them superuser -privileges. - -Given that NixOS - a system that leverages Nixpkgs for superusers - is already -bundled inside Nixpkgs tree, a fortiori HM - a system that leverages Nixpkgs for -basic users - should be included as the default, Nixpkgs-blessed system for -basic users. - -Further, this assimilation will benefit two interesting sets of people: - -01. Users of Nixpkgs and/or NixOS that are reluctant in using HM, since it is - neither official nor well-integrated into Nixpkgs workflow. - -01. Users of NixOS that already use HM in tandem, as a convenient way of - separating basic users' business from system administration tasks. - -Another great advantage of assimilating HM to Nixpkgs is a tighter integration -between both projects: - -01. Merging HM into Nixpkgs eliminates a barrier between both projects, - conveying more flexibility in code sharing, deduplication and refactoring in - general. - -01. Refactors, reformulations, deprecations and removals of packages and other - related functionalities are commonplace around Nixpkgs. Since HM is - dependent on Nixpkgs, it needs to monitor and synchronize such activities. - - The eventual assimilation proposed here drops those issues dramatically. - -01. The merge of communities brings a new point of view about package maintenace - in general. - - NixOS is the main point of structured conglomeration of packages; because of - this, Nixpkgs is arguably more inclined to favor a superuser view of system - administration. - - Bringing HM to Nixpkgs provides a new point of view, more akin to the basic - user. - -01. Making HM an official, blessed tool conveys more credibility to both - Nixpkgs and HM. - -# Detailed design -[design]: #detailed-design - -There are many possible approaches for this assimilation. Here I will propose a sketch: - - -01. Prepare HM to migration - - Currently Nixpkgs monorepo requires certain rules to accept code. - -01. Prepare Nixpkgs to migration too - - There is some expectation of preparing Nixpkgs to deal with the big input of - new code. A merge train will be useful here and in subsequent steps. - -01. Merge HM repository so that its files are kept in `home-manager` directory - -01. Polish the rough edges - -01. Profit! - -# Examples and Interactions -[examples-and-interactions]: #examples-and-interactions - -Ideally, after the assimilation, a basic user will experience few to no changes -in their workflow. The channels of distribution of both Nixpkgs and HM will be -merged, promoting a cleanup on setups that otherwise would need synchronization. - -On the other hand, from this assimilation forward the typical package maintainer -will interact with potentially two sets of too similar module systems. This -brings a momentum to deduplicate code and build abstractions, however this is -not in the scope of this RFC. - -# Drawbacks -[drawbacks]: #drawbacks - -The main drawback of this assimilation stem from the resulting complexity. - -## Standardization - -There are some discrepancies between the practices of both communities. How they -should be accomodated? - -## Synchronize the communities - -There are almost 660 contributors in HM to this date. How they should be -allocated? - -Ideally they should keep the same roles. - -## CI - -Currently HM uses its own setup for continuous integration. Ideally the Nixpkgs -setup should be updated to include HM's specific needs. - -# Alternatives -[alternatives]: #alternatives - -The alternatives are - -- The trivial "do nothing" - - It just exacerbates the status quo, bringing nothing in the long term. - -- Bless another home management tool - - HM is battle-tested and well renowned. There is no other tool remotely - comparable to it. - -- Build a home management tool from scratch - - This alternative dismisses the know-how accumulated by HM. An acceptable - middle ground would be to create some "library extension" to accomodate future - HM-like modules and use that extension to migrate HM modules. - -# Prior art -[prior-art]: #prior-art - -As an example of prior art, there is our Scheme-based cousin, Guix Software -Distribution. Since at least 2022 AD they bring a similar tool, conveniently -called Guix Home. - -The nicest thing about this tool is that it is tightly integrated with Guix, to -the point of `home` being a mere subcommand of `guix`. - -# Unresolved questions -[unresolved]: #unresolved-questions - -How the future package inclusions should be carried out? - -# Future work -[future]: #future-work - -- Update an extend the CI -- Set expectations on portability among present and future platforms Nixpkgs - supports - - Especially outside NixOS - - Especially outside Linux -- Factor HM and NixOS's shared code into some service abstraction structure - -# References -[references]: #references - -- [Keeping One's Home - Tidy](https://guix.gnu.org/en/blog/2022/keeping-ones-home-tidy/), by Ludovic - Courtès -- [Guix Home - Configuration](https://guix.gnu.org/manual/devel/en/html_node/Home-Configuration.html) From eb52164c4bc91a038799e8bce9406c7749e8190f Mon Sep 17 00:00:00 2001 From: Anderson Torres Date: Wed, 11 Sep 2024 20:56:49 -0300 Subject: [PATCH 03/14] RFC draft HMT --- rfcs/9999-user-management.md | 306 +++++++++++++++++++++++++++++++++++ 1 file changed, 306 insertions(+) create mode 100644 rfcs/9999-user-management.md diff --git a/rfcs/9999-user-management.md b/rfcs/9999-user-management.md new file mode 100644 index 000000000..16b17f585 --- /dev/null +++ b/rfcs/9999-user-management.md @@ -0,0 +1,306 @@ +--- +feature: I'm Gonna Build My Own Manager With Blackjack and Modules! +start-date: (fill me in with today's date, YYYY-MM-DD) +author: Anderson Torres +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 + +Enhance Nixpkgs monorepo with a declarative management system for basic users. + +# Terminology +[terminology]: #terminology + +Henceforth, + +- The typical unprivileged user of a system will be called _basic user_; +- The typical privileged user of a system will be called _superuser_; + +# Motivation +[motivation]: #motivation + +[Nixpkgs](https://github.com/NixOS/nixpkgs) is by a far margin the largest +packageset in this existence, according to +[Repology](https://repology.org/repository/nix_unstable). + +In principle, currently the Nix interpreter and evaluator already leverage +Nixpkgs for basic users. However, this raw usage is not very ergonomical, +especially when compared to the structured model provided by NixOS. + +In this panorama, the average user has two extreme options here: + +- system-wide configuration via NixOS, requiring superuser privileges; +- ad-hoc management via raw Nix commands, especially the not-recommended + `nix-env`. + +This RFC proposes to fill this gap: a structured model of system management for +basic users that does not require superuser privileges to be deployed. + +# Detailed Design +[design]: #detailed-design + +In a dedicated directory inside the Nixpkgs monorepo a well-crafted set of core +modules, plus some companion modules, will be created and maintained. + +Further, a companion toolset (henceforth called `hometool`) to manipulate and +deploy the home environment will be provided. + +This toolset plus module set should provide the following properties: + +- Declarativeness + + Users can specify the configuration of their systems in Nix language, by a set + of detailed descriptions. + +- Immutability + + As a consequence of declarativeness, the resulting descriptions are immutable. + It allows comparing them by knowing precisely what changed between + configurations. + +- Customizability + + Users can derive specialized module configurations from current module set. + +- Extensibility + + Users can extend the module set by writing their own, leveraged by overlay and + other Nix language constructs. + +- Scalability + + `hometool` should be scalable from the simplest to the more complex user + environment definitions. + +- Documentation + + Both the `hometool` and the moduleset should be well documented. + +- Human Friendliness + + This `hometool` should be approachable with clear and understandable logging + messages, plus the aforementioned documentation. + +# Examples and Interactions +[examples-and-interactions]: #examples-and-interactions + +Let's call `hometool` the tool used by the basic users to deploy and deal with +their configurations. + +```shell +$> ### help message, possibly pointing to further detailed and/or specialized help, like `--all`, `--modules` +$> hometool help +$> ### generate a sample config; can be enhanced with a wizard +$> hometool sample-config > user-configuration.nix +$> ### because we like to tweak things a bit +$> emacs user-configuration.nix +$> ### build it first without deploying it yet +$> hometool build +$> ### a container to test it before deploying - for us paranoids! +$> hometool container +$> ### now install it! +$> hometool install +$> ### list the generations +$> hometool generations list +$> ### list differences between generations +$> hometool generations diff 9 10 +$> ### select a specific generation +$> hometool generations select 10 +$> ### remove older generations, marking them to be garbage-collected +$> hometool generations remove 1-8 +``` + +# Drawbacks +[drawbacks]: #drawbacks + +- Why not to keep this tool outside Nixpkgs monorepo? + + It can be argued that overlays and other facilities provided by Nix language + allow to keep entire projects outside the Nixpkgs monorepo. + + However, any of those projects suffer of an unpleasant phenomenon: the second + class citizen repo. + + Basically, a repository outside the monorepo will not receive the same level + of care and attention of a project inside the monorepo. It happens because, + among other things, + + - it is harder to pay attention in multiple repositories at the same time slot + than only one; + - it is harder to deal with pieces of code contained in distinct repositories; + - it is harder to synchronize multiple repositories; + + Because of those hurdles, it becomes easier to ignore the repos outside the + main monorepo. + + As a consequence, breaking changes in the monorepo are prone to be decided + without taking the satellite repos into consideration. This situation leads + the satellite repos to deal with the extra work of synchronizing with the + recent changes. + + By living inside the main monorepo, the problems exposed above diminishes + drastically. + + Further, having this home management toolset inside the monorepo brings many + advantages: + + - No longer dealing with synchronization among projects + - Better strategies for code deduplication, sharing and refactoring + - Direct access to the most recent enhancements available + + Indeed this is precisely what happens in NixOS already: when a program is + added, a NixOS module and test suite can be plugged in the same pull + request, with few to no bureaucracy. + + - Reputation + + A home management toolset kept in the monorepo has the social add-on of + being better regarded by the Nixpkgs community as a whole, since there will + be no barriers for contribution from this same community. + +- The monorepo will increase in size. + + The increase in size is expected to be small. + + Since we are building a set of modules to deal with the Nixpkgs packageset, a + good heuristic approximation of the worst case would be the current size of + `nixos` directory - after all, we want NixOS without superuser privileges. + + A quick `du` returns something like this. + + ```shell + $> du -sh nixos/ pkgs/ + 024572 nixos/ + 379536 pkgs/ + ``` + + By the numbers above, obtained locally at 2024-09-13, `nixos` occupies less + than 7% of the sum of both `nixos + pkgs`. A quick and dirty calculation would + bring a similar 7% increase in size. + + This is certainly a crude calculation, however we are ignoring many factors + that will bring these numbers down. Namely: + + - Refactorings + + Similar code can be factored and abstracted. + + - Code sharing + + Code that was initially projected for basic user management can be found + useful for superuser management too. + +- Code duplications. + + Code duplications can be refactored as they appear. + + Indeed it is way easier to deal with code duplication in a monorepo: since the + barrier of communication between multiple repositories disappears, a + duplicated code can be factored more easily, requiring just one pull request + instead of one per repo. + +- Evaluation times of monorepo will increase. + + The increase in evaluation time is a bit harder to measure. However, + + - "increase in evaluation time" was not an argument strong enough for undoing + the NixOS assimilation; + - arguably, the increase in evaluation time will be felt by those effectively + using the hometool; the remaining users will not be signficatively affected. + - a similar argument for the increase in size can be crafted here. + + The perceived advantages of having this module system surpasses these small + disadvantages + +# Alternatives +[alternatives]: #alternatives + +- The trivial "do nothing". + +- Promote an alternative toolset. + + The most viable alternative in this field is home-manager. However it is not + so easy to assimilate a consolidated project within another consolidated + project, not only in terms of source code, but also in terms of community and + decision-making. + + A better approach would be promote some form of a healthy competition, in + which home-manager and hometool are different projects competing for the same + niche, each with their own teams, communities, design projects etc.; further, + both teams are free to share code between them, provided they follow their + corresponding licenses in doing so. + +- Promote `guix home` + + What? Lisp is cool! + +# Prior art +[prior-art]: #prior-art + +## Guix Home + +As an example of prior art, there is our Scheme-based cousin, Guix Software +Distribution. Since at least 2022 AD they bring a similar tool, conveniently +called Guix Home. + +The nicest thing about this tool is that it is tightly integrated with Guix, to +the point of `home` being a mere subcommand of `guix`. + +## Home Manager + +Home Manager is a well-established toolset that leverages the Nixpkgs module +system to allow basic users to manage their user-specific environment in a +declarative way. + +## Wrapper Manager + +Wrapper-manager is a Nix library that allows the user to configure your favorite +applications without adding files into `~/.config`. This is done by creating +wrapper scripts that set the appropriate environment set - variables, flags, +configuration files etc. - to the wrapped program. + +# Unresolved questions +[unresolved]: #unresolved-questions + +Given that this tool will live inside Nixpkgs monorepo, it is expected that +future packages will interact with this new tool. How those interactions should +be dealt? + +# Future work +[future]: #future-work + +- Update an extend the CI +- Set expectations on portability among present and future platforms Nixpkgs + supports + - Especially outside NixOS + - Especially outside Linux + +# References +[references]: #references + +- [Home Manager](https://nix-community.github.io/home-manager/) +- [Keeping One's Home + Tidy](https://guix.gnu.org/en/blog/2022/keeping-ones-home-tidy/), by Ludovic + Courtès +- [Guix Home + Configuration](https://guix.gnu.org/manual/devel/en/html_node/Home-Configuration.html) +- [Wrapper Manager](https://github.com/viperML/wrapper-manager) +- [Stop Using nix-env](https://stop-using-nix-env.privatevoid.net/) +- [Overlay for User Packages](https://gist.github.com/LnL7/570349866bb69467d0caf5cb175faa74) by LnL7 +- [BuilEnv-based Declarative User + Environment](https://gist.github.com/lheckemann/402e61e8e53f136f239ecd8c17ab1deb) + by lheckellman +- [Nix Home](https://github.com/museoa/nix-home/) + - Forked and archived from [Nix Home](https://github.com/sheenobu/nix-home/) + - with patches saved from other forks +- [nix-config from akavel](https://github.com/akavel/nix-config/tree/master/.nixpkgs) + - https://github.com/sheenobu/nix-home/issues/16 + - https://github.com/akavel/nix-config/blob/510f36861cc4a641bd976ad25dd339949b47339d/.nixpkgs/nix-home.nix + - https://github.com/akavel/nix-config/blob/510f36861cc4a641bd976ad25dd339949b47339d/.nixpkgs/nix-home.sh + - https://github.com/akavel/nix-config/blob/510f36861cc4a641bd976ad25dd339949b47339d/.nixpkgs/config.nix#L57 +- [GNU Stow](https://www.gnu.org/software/stow/) From c294114aeb6baa00a0cecbfb50a45a1f48ef1de3 Mon Sep 17 00:00:00 2001 From: Anderson Torres Date: Fri, 20 Sep 2024 14:03:03 -0300 Subject: [PATCH 04/14] Preparing for the world (of Nixpkgs) Start date coauthor nyanbinary --- rfcs/{9999-user-management.md => 0182-user-management.md} | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) rename rfcs/{9999-user-management.md => 0182-user-management.md} (98%) diff --git a/rfcs/9999-user-management.md b/rfcs/0182-user-management.md similarity index 98% rename from rfcs/9999-user-management.md rename to rfcs/0182-user-management.md index 16b17f585..cb786a154 100644 --- a/rfcs/9999-user-management.md +++ b/rfcs/0182-user-management.md @@ -1,8 +1,8 @@ --- -feature: I'm Gonna Build My Own Manager With Blackjack and Modules! -start-date: (fill me in with today's date, YYYY-MM-DD) +feature: I'm Gonna Build My Own Home Tool With Blackjack and Modules! +start-date: 2024-09-20 author: Anderson Torres -co-authors: (find a buddy later to help out with the RFC) +co-authors: nyanbinary 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) From 35e898469f59fc56a7e2450592c56c08abd81ab9 Mon Sep 17 00:00:00 2001 From: Anderson Torres Date: Fri, 20 Sep 2024 15:06:31 -0300 Subject: [PATCH 05/14] Update nyabinary handle Co-authored-by: Niko Cantero <97130632+nyabinary@users.noreply.github.com> --- rfcs/0182-user-management.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0182-user-management.md b/rfcs/0182-user-management.md index cb786a154..a11b99a46 100644 --- a/rfcs/0182-user-management.md +++ b/rfcs/0182-user-management.md @@ -2,7 +2,7 @@ feature: I'm Gonna Build My Own Home Tool With Blackjack and Modules! start-date: 2024-09-20 author: Anderson Torres -co-authors: nyanbinary +co-authors: @nyabinary 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) From ae645a3c4b0c072ae1938fb4a64355496dd385dd Mon Sep 17 00:00:00 2001 From: Anderson Torres Date: Fri, 20 Sep 2024 16:26:53 -0300 Subject: [PATCH 06/14] Nix evaluators are faster! --- rfcs/0182-user-management.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/rfcs/0182-user-management.md b/rfcs/0182-user-management.md index a11b99a46..800d6d498 100644 --- a/rfcs/0182-user-management.md +++ b/rfcs/0182-user-management.md @@ -215,7 +215,9 @@ $> hometool generations remove 1-8 - a similar argument for the increase in size can be crafted here. The perceived advantages of having this module system surpasses these small - disadvantages + disadvantages about size and evaluation time. + + Further, there are initiatives focused on optimizing the Nix evaluators. # Alternatives [alternatives]: #alternatives From 1abecb81c40f484c277258232b4fd318d13a16e1 Mon Sep 17 00:00:00 2001 From: Anderson Torres Date: Fri, 20 Sep 2024 16:27:39 -0300 Subject: [PATCH 07/14] reword --- rfcs/0182-user-management.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rfcs/0182-user-management.md b/rfcs/0182-user-management.md index 800d6d498..cb706fe91 100644 --- a/rfcs/0182-user-management.md +++ b/rfcs/0182-user-management.md @@ -250,8 +250,8 @@ As an example of prior art, there is our Scheme-based cousin, Guix Software Distribution. Since at least 2022 AD they bring a similar tool, conveniently called Guix Home. -The nicest thing about this tool is that it is tightly integrated with Guix, to -the point of `home` being a mere subcommand of `guix`. +The nicest thing about this tool is its tight integration with Guix as a whole, +to the point of `home` being a mere subcommand of `guix`. ## Home Manager From 4c2429eb97cf41c61d3f9e68d6530f3174fd4b0e Mon Sep 17 00:00:00 2001 From: Anderson Torres Date: Sat, 21 Sep 2024 22:33:46 -0300 Subject: [PATCH 08/14] rename commands --- rfcs/0182-user-management.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/rfcs/0182-user-management.md b/rfcs/0182-user-management.md index cb706fe91..1901774be 100644 --- a/rfcs/0182-user-management.md +++ b/rfcs/0182-user-management.md @@ -101,17 +101,17 @@ $> ### because we like to tweak things a bit $> emacs user-configuration.nix $> ### build it first without deploying it yet $> hometool build -$> ### a container to test it before deploying - for us paranoids! -$> hometool container +$> ### a VM to test it before deploying - for us paranoids! +$> hometool build-vm $> ### now install it! -$> hometool install +$> hometool switch $> ### list the generations $> hometool generations list $> ### list differences between generations $> hometool generations diff 9 10 $> ### select a specific generation -$> hometool generations select 10 -$> ### remove older generations, marking them to be garbage-collected +$> hometool generations switch 10 +$> ### remove older generations -- marking them to be garbage-collected $> hometool generations remove 1-8 ``` From 8830f899456a98964316a56cfdf390f63a0340f8 Mon Sep 17 00:00:00 2001 From: Anderson Torres Date: Sat, 21 Sep 2024 22:34:04 -0300 Subject: [PATCH 09/14] typo --- rfcs/0182-user-management.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0182-user-management.md b/rfcs/0182-user-management.md index 1901774be..0209b9acc 100644 --- a/rfcs/0182-user-management.md +++ b/rfcs/0182-user-management.md @@ -276,7 +276,7 @@ be dealt? # Future work [future]: #future-work -- Update an extend the CI +- Update and extend the CI - Set expectations on portability among present and future platforms Nixpkgs supports - Especially outside NixOS From 1c669d176f1f5f40a1d8d4f708e0d285e0e8e6f5 Mon Sep 17 00:00:00 2001 From: Anderson Torres Date: Wed, 2 Oct 2024 22:50:37 -0300 Subject: [PATCH 10/14] A huge and sketchy reword --- rfcs/0182-user-management.md | 90 +++++++++++++++++++++++++----------- 1 file changed, 63 insertions(+), 27 deletions(-) diff --git a/rfcs/0182-user-management.md b/rfcs/0182-user-management.md index 0209b9acc..283479d41 100644 --- a/rfcs/0182-user-management.md +++ b/rfcs/0182-user-management.md @@ -41,16 +41,30 @@ In this panorama, the average user has two extreme options here: This RFC proposes to fill this gap: a structured model of system management for basic users that does not require superuser privileges to be deployed. +Let's call it `hometool`. + # Detailed Design [design]: #detailed-design -In a dedicated directory inside the Nixpkgs monorepo a well-crafted set of core -modules, plus some companion modules, will be created and maintained. +`hometool` has two components: + +1. A driver program, hereinafter called `hometool`. + + Among other related tasks, this tool has the role of realizing the + description of a home environment. + + As expected from a driver, this tool will rely on other programs to execute + its intents; the most immediate one being the Nix evaluator. + +2. A set of carefully crafted modules, leveraged by Nix Module System. -Further, a companion toolset (henceforth called `hometool`) to manipulate and -deploy the home environment will be provided. + The moduleset should reside in `hometool/` directory at the root of Nixpkgs + monorepo, similar to how it happens to `nixos/` nowadays. -This toolset plus module set should provide the following properties: +# Expectations +[expectations]: #expectations + +The set of components above should provide the following properties: - Declarativeness @@ -69,8 +83,7 @@ This toolset plus module set should provide the following properties: - Extensibility - Users can extend the module set by writing their own, leveraged by overlay and - other Nix language constructs. + Users can extend the module set by writing their own. - Scalability @@ -89,13 +102,12 @@ This toolset plus module set should provide the following properties: # Examples and Interactions [examples-and-interactions]: #examples-and-interactions -Let's call `hometool` the tool used by the basic users to deploy and deal with -their configurations. +Here is a small example of what is expected -```shell +```console $> ### help message, possibly pointing to further detailed and/or specialized help, like `--all`, `--modules` $> hometool help -$> ### generate a sample config; can be enhanced with a wizard +$> ### generate a sample config $> hometool sample-config > user-configuration.nix $> ### because we like to tweak things a bit $> emacs user-configuration.nix @@ -111,7 +123,7 @@ $> ### list differences between generations $> hometool generations diff 9 10 $> ### select a specific generation $> hometool generations switch 10 -$> ### remove older generations -- marking them to be garbage-collected +$> ### remove older generations $> hometool generations remove 1-8 ``` @@ -193,7 +205,7 @@ $> hometool generations remove 1-8 - Code sharing Code that was initially projected for basic user management can be found - useful for superuser management too. + useful for superuser management too; and vice-versa. - Code duplications. @@ -217,29 +229,53 @@ $> hometool generations remove 1-8 The perceived advantages of having this module system surpasses these small disadvantages about size and evaluation time. - Further, there are initiatives focused on optimizing the Nix evaluators. + Further, outside the scope of Nixpkgs, there are initiatives focused on + optimizing the Nix evaluators. # Alternatives [alternatives]: #alternatives -- The trivial "do nothing". +## The trivial "do nothing" + +Trivially keeping the status quo. + +## Promote `guix-home` + +What? Lisp is cool! + +## Promote `home-manager` + +Now a serious alternative worthy of consideration. + +Home Manager has the most obvious and the most powerful advantage: + +It exists and is working well. Further, it is battle-tested and encodes a lot of +knowledge in its 8 years lifespan and more than 3.7k commits. + +However, it has some non-negligible disadvantages: + +- The current code does not follow the same standards of the current Nixpkgs + monorepo + + - many modules rely on stringly `extraConfig` instead of structured + `settings`, contra RFC 0042; + +- Many instances of technical debt, something expected in such a long-lived + project: -- Promote an alternative toolset. + - excessive uses of `with lib;` - The most viable alternative in this field is home-manager. However it is not - so easy to assimilate a consolidated project within another consolidated - project, not only in terms of source code, but also in terms of community and - decision-making. + - hacky solutions like the dangerous `mkOutOfStoreSymlink`: + https://github.com/nix-community/home-manager/issues/3032 - A better approach would be promote some form of a healthy competition, in - which home-manager and hometool are different projects competing for the same - niche, each with their own teams, communities, design projects etc.; further, - both teams are free to share code between them, provided they follow their - corresponding licenses in doing so. + - under-documented workarounds -- Promote `guix home` + - too much reliance on Bash and its nasty idiosyncrasies - What? Lisp is cool! +On the other hand, starting from a cleaner slate has the opposite set of +advantages and disadvantages: the kickstart of a project is too wide and it is +easier to get lost. On the other hand, there is considerably more freedom to +prototype and test ideas, older and newer. # Prior art [prior-art]: #prior-art From 45f592189dc9d7aba1f3726c98eba30933f36c35 Mon Sep 17 00:00:00 2001 From: Anderson Torres Date: Wed, 2 Oct 2024 23:17:39 -0300 Subject: [PATCH 11/14] cite nixos-rebuild en passant --- rfcs/0182-user-management.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/rfcs/0182-user-management.md b/rfcs/0182-user-management.md index 283479d41..5e74a7f79 100644 --- a/rfcs/0182-user-management.md +++ b/rfcs/0182-user-management.md @@ -302,6 +302,11 @@ applications without adding files into `~/.config`. This is done by creating wrapper scripts that set the appropriate environment set - variables, flags, configuration files etc. - to the wrapped program. +## nixos-rebuild + +In the Nix world, nixos-rebuild is the master tool in terms of deployment of a +Nix-based configuration, albeit being system-wide. + # Unresolved questions [unresolved]: #unresolved-questions From 4f8fe5b031c0af7b4e2751912090759adab544a4 Mon Sep 17 00:00:00 2001 From: Anderson Torres Date: Wed, 2 Oct 2024 23:17:55 -0300 Subject: [PATCH 12/14] shorten expectations on portability --- rfcs/0182-user-management.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/rfcs/0182-user-management.md b/rfcs/0182-user-management.md index 5e74a7f79..37e8b9b49 100644 --- a/rfcs/0182-user-management.md +++ b/rfcs/0182-user-management.md @@ -318,8 +318,7 @@ be dealt? [future]: #future-work - Update and extend the CI -- Set expectations on portability among present and future platforms Nixpkgs - supports +- Set expectations on portability - Especially outside NixOS - Especially outside Linux From 15ceaf7e39b342e54516878458e5cfc6fdc33fa9 Mon Sep 17 00:00:00 2001 From: Anderson Torres Date: Wed, 2 Oct 2024 23:18:17 -0300 Subject: [PATCH 13/14] new link --- rfcs/0182-user-management.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/rfcs/0182-user-management.md b/rfcs/0182-user-management.md index 37e8b9b49..33985b41f 100644 --- a/rfcs/0182-user-management.md +++ b/rfcs/0182-user-management.md @@ -346,3 +346,5 @@ be dealt? - https://github.com/akavel/nix-config/blob/510f36861cc4a641bd976ad25dd339949b47339d/.nixpkgs/nix-home.sh - https://github.com/akavel/nix-config/blob/510f36861cc4a641bd976ad25dd339949b47339d/.nixpkgs/config.nix#L57 - [GNU Stow](https://www.gnu.org/software/stow/) +- [Dropping Home Manager](https://ayats.org/blog/no-home-manager), an article from ViperML + containing some criticism about home-manager From b71fea9a59f6e0b193bac370c08e4bfda9b9bbcc Mon Sep 17 00:00:00 2001 From: Anderson Torres Date: Wed, 2 Oct 2024 23:18:42 -0300 Subject: [PATCH 14/14] backquote protecting `@` --- rfcs/0182-user-management.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0182-user-management.md b/rfcs/0182-user-management.md index 33985b41f..8c8e68901 100644 --- a/rfcs/0182-user-management.md +++ b/rfcs/0182-user-management.md @@ -2,7 +2,7 @@ feature: I'm Gonna Build My Own Home Tool With Blackjack and Modules! start-date: 2024-09-20 author: Anderson Torres -co-authors: @nyabinary +co-authors: `@nyabinary` 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)