Ideally both channels would be merged.
The modules are very readable, similar to those from NixOS.
The harder part is the Bash scripts, as expected.
This is basically what HM does - it uses the existing module system in order to generate configuration.
The duplication happened mostly because they are not in the same repo.
I beg to differ.
I announced my intent in their Matrix channel, a not so long time ago. For the sake of announcement I will do another right now.
Thereâs no real testing or even code review, stuff just gets merged if it âlooks goodâ. For concrete examples, the sway and waybar modules were so awful I reworked my config just to get rid of HM. Even their systemd âabstractionâ is not really an abstraction, just a straight toINI that doesnât account for upstream service files.
Again I want to reiterate: the need is not for HM, the need is for user-level config management. The only reason HM keeps coming up is that itâs currently the only well-known option in that space. We can do much better.
I was not so lucky in my personal experience.
How much longer we should wait for those âweâ that âcan do much betterâ?
I didnât say it with folding HM into nixpkgs in mind, but I have previously wondered aloud if moving module-related utility logic towards package passthrus might build leverage by enabling more reuse across module systems and dev shells.
I think the last time I mentioned it was in:
Yes we should merge it into the Nixpkgs/NixOS repo, so we can start deduplicating with NixOS, as others have said.
Kde configuration requires to alter their files in place as it too often uses the same file for both configuration and state
I think we should create several middle grounds between the package and the NixOS modules (which must be used as a whole for now), including service abstraction, wrapper abstraction and dotfiles abstraction. We may need several RFCs to advance this.
The RFC process is all out of sorts (as someone far removed from it, admittedly) but perhaps folks can point me to stuff for nix RFCs and such that sorta kinda mirror whatâs in here (process, roles, etc) https://www.rfc-editor.org/rfc/rfc6635.txt - weâre not that important but seems like a good document for sharper eyes to peruse and gather takeaways from (if they have yet to do so). Anyway, I sorta like this idea and the need for âuser-level configuration managementâ grows by the day
I think we need not more plans, but more experimentation.
Itâs hard to reduplicate when things are in different repos, and we just donât know what sort of abstraction a 3rd repo that NixOS and home-manager should both use should look like. Conversely, with both things in the same repo, we can start deduplicating individual modules and iterative discover what the body of common modules should look it.
Same reason I would want to through NixBSD in the someday and then iteratively deduplicate.
I guess after merging the HM we should then also merge nix-darwin and possibly system-manager?
Yes, good point! This is the first I am learning of system-manager too; that is a nice idea that should be able to be gotten almost âfor freeâ as midpoint between all the others
Why should everything be in a monorepo though? In the 3.5 years Iâve been using nix the nixpkgs repo has grown in size from roughly 19MB to 42MB. But the software I use has not doubled. So effectively Iâm wasting more MBs per usage of nix-packaged software than I did a couple of years ago. And itâs not just me, this is the case for every single user of nixpkgs. If we add Home Manager, nix-darwin, system-manager, maybe other stuff, that percentage of wasted bandwidth and storage will only grow. I have really noticed the substantial increase in size in download times which are becoming increasingly more annoying to put up with.
I get the point that it is easier to experiment in a monorepo, but on the other hand itâs nowhere near impossible to experiment across many repos. It might be worth experimenting with a more modular setup of the repositories to make code sharing possible without just putting everything in nixpkgs and exploding its size.
While youâre at it, you might as well merge nixos-hardware into nixpkgs too because why not ;p
As far as I remember, NixOS the operating system was a separate repo, but it lagged behind Nixpkgs the package collection.
Before the creation of overlays and flakes, it was a hard thing to sync them.
Now that they live in the same monorepo, it is way easier to update both a Nix package and its corresponding NixOS module.
Also it is way easier to make integration tests for each of them.
A long time ago I was talking with Okada about splitting NixOS into its own repo, but we never tried to do it.
Nonetheless I still advocate for a monorepo. Filling three PRs for a single package is annoying enough.
Further, NixOS is less than 8% of Nixpkgs monorepo, and the whole HM (plus dotgit) occupies just two NixOSes.
This particular problem will not disappear, since we do not have titanic barriers to include software.
Also, I have vented my complaint with multirepos a short time ago:
Hey, are you stealing my idea? Nops, I steal that idea before
This is somewhat of a tangent, but how code is organised and how its artefacts are deployed are two independent questions. Maintaining code in one file system tree and with one version history simplifies its manipulation a great deal. It doesnât mean that the result has to be shipped in the same shape. One can automatically split out components into separate units so they can be deployed independently. This requires maintaining clean internal boundaries, and while thatâs a bit of effort, itâs a lot less effort than working around stronger but inflexible boundaries, such as separate repositories.
Many years ago I thought that repositories are natural component boundaries and their rigidity helps with maintaining interface discipline. If you dig around youâll even find me posting about this. But with experience I realised that this completely neglects the value of being able to do sweeping atomic changes, the high cost of learning techniques or building tools to work across separate repositories, and the low cost of automatically producing simpler units of deployment from a unified code base.
In the end it of course doesnât matter where the code lives. What matters is how much effort it is to work with it for todayâs and tomorrowâs maintainers, those people who can really make a difference. The most valuable thing we have is peopleâs attention and time, and we should optimize for that.
Wow thanks for the numbers! Iâve never thought about the relative sizes before.
Here is a fun thought experiment: even if we decided to split back out NixOS from Nixpkgs, I would still want NixOS, Home-Manager, Nix-Darwin, System-Manager, etc. in the same repo. The âmodule-using things for system configurationâ should be much more tightly integrated with each other than with the bare package set.
While small and insignificant, NixNG (or whatever I rename it too when I get a good idea) would benefit too, many modules are partial copy-pastes from NixOS, the only bits that differ are the actual config attrs. I have thought about pulling in options from NixOS but it would be hard to keep in sync.
i love the idea of a common options file and then each implementation writing their own separate file containing config
some argue thatâs duplication but i believe without that you run into too many problems
It looks like the RFC 163 is way fundamental, paving the way to all those projects:
and why not,
any idea how that is progressing? i believe there hasnât been too much activity lately