mirror of
https://github.com/NixOS/rfcs.git
synced 2025-11-09 03:56:11 +01:00
remove assimilation
This commit is contained in:
Anderson Torres
parent
2e84b448ac
commit
7628248efc
1 changed files with 0 additions and 197 deletions
|
|
@ -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)
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue