nix-darwin
nix-darwin copied to clipboard
LnL7
Looking for additional maintainers
I've been talking to @LnL7 about onboarding additional maintainers.
We have to make sure that the quality of the repository is preserved.
@LnL7 could you take some time to write down the process how to maintain the repo - how to test, etc? It doesn't have to be perfect from the start, just something simple to follow.
I admit this is probably a bit premature, but I'm definitely willing to help maintain the project.
For me there are 2 important things that are a priority for the project.
- safety: Unlike NixOS system configuration here has to live next to the existing operating system. A number of things are intentionally blocked off to prevent (less experienced) users from shooting themselves in the foot. As an example with a few exceptions you can't manage files in /etc if they're already created by macOS. There's no guarantee that making sudoers a symlink is something that can't cause problems with the macOS boot or login at some point.
- compatibility: This project is not versioned together with nixpkgs like NixOS is. The darwin builds for packages are also generally less stable on darwin so it's not unusual for people to stick with an older version for a while until problems with a certain build are resolved. The lib functions and modules in nixpkgs often take the liberty to change "internal" things in one go together but that's not possible here. Same goes for renaming options in modules, since there are no real releases here I try to give users ample time to migrate.
For testing I don't really have a nice answer. Working on activation scripts except for testing the diff logic in a more isolated form generally just means running it on a vm.
Given this I'm not inclined to just add a bunch of maintainers to merge things faster if some users could end up with a broken system as a result (I've managed to make a system unbootable before). However most of these dangers are contained within the activation scripts. Adding a new service module or updating some functionality based on the NixOS modules is a lot more approachable compared to all the bash foo and system details needed for activation scripts. So perhaps some sort of maintainer tiers would be a good approach?
That definitely sounds like a good approach.
To add on to the point about safety: in my opinion, it would definitely be beneficial to require at least 2 (or some other number) reviews from maintainers before things are merged.
I think a good course of action would be moving the repository to nix-community. That way, more eyes would be on it, and potentially more contributions/work. It could also solve the maintainer ship problem.
Agreed.
I was going to propose this before this issue was created, but was unsure how to go about that.
@domenkozar @LnL7 I'm curious if there's been any progress made on this effort, since this issue has been dormant for a few months.
I think that a good first step would be moving the repo to the nix-community org, and then going from there with adding maintainers and such, at least to review/merge fixes to the low risk components like modules, and to close issues.
I fully support that, but we have to make sure we come with a good system of reviews that @LnL7 agrees with :)
Since it's a recurring topic in the comments, I think moving the repo is somewhat beside the point. There could be reasons to do so in the future but for now I would like to see some actual maintainers/contributors instead.
To clarify my previous comment, I'm definitely open to adding a few maintainers. Changes to the core parts require discussion but apart from that there's a lot that can be done to improve and extend the project. If you're interested in becoming a maintainer I'd say general knowledge of macOS is more useful compared to nixos/nixpkgs, so I think a basic understanding of the module system is more than enough. Apart from having made some contributions to the project first would be nice (more to indicate interest than anything else).
I'll bump my offer to help from https://github.com/LnL7/nix-darwin/issues/358#issuecomment-917718050, just since it's at the very top.
(I'm a Nixpkgs committer, if that helps instills any trust in me :)
versioned together with nixpkgs like NixOS
I totally agree with this point. Also having versioned releases of nix-darwin so a version could be pinned in a system configuration.
I wonder if the project would benefit being under the nix-community ?
@domenkozar @LnL7 I would like to nominate myself and @emilazy as maintainers for nix-darwin, as we have both been actively contributing to the repository in recent history: https://github.com/LnL7/nix-darwin/graphs/contributors
If I'm made a maintainer, my goals for nix-darwin would be trying to reduce the amount of open PRs (by reviewing them or closing stale PRs) and the amount of open issues (stale or issues that have no responses to them).
Well, I do feel somewhat qualified after https://github.com/LnL7/nix-darwin/pull/707, https://github.com/LnL7/nix-darwin/pull/723, and my local work on https://github.com/LnL7/nix-darwin/issues/96, so I'm happy to accept the nomination :) I'm subscribed to the whole nix-darwin repository and interested in helping fix issues and work directly on improvements. I can't guarantee a consistent amount of work, as life can always get in the way (I did very little in the Nix sphere in 2021 as a result), but I'm interested in bringing nix-darwin into closer alignment and compatibility with NixOS, making things simpler and more maintainable where possible, ensuring the functionality we expose is robust, and of course reviewing others' PRs. I care about not breaking people's systems and would not push directly to master or merge controversial or dangerous changes unilaterally.
I've been using nix-darwin for about four years now, and it's great, but I think that the small number of active contributors and even smaller number of committers is somewhat holding it back, and I'd like to help with that if I can. I also second @Enzime's self-nomination on the basis of their great recent work.
I wouldn't mind helping. Idk how active on here I'd be however, and at this point I only have a couple months experience with nix (although I have put in alot of time learning nix since then). I probably wouldn't feel comfortable merging or approving a pr without guidance or a checklist to follow (to ensure I've covered my bases). I do have a pr open currently #716.
I also wanted to address this point from @LnL7's earlier comment:
- compatibility: This project is not versioned together with nixpkgs like NixOS is. The darwin builds for packages are also generally less stable on darwin so it's not unusual for people to stick with an older version for a while until problems with a certain build are resolved. The lib functions and modules in nixpkgs often take the liberty to change "internal" things in one go together but that's not possible here. Same goes for renaming options in modules, since there are no real releases here I try to give users ample time to migrate.
I agree that this is a big challenge for nix-darwin maintenance; it requires a lot of tricky accommodation and leads to a lot of inadvertent breakage. It also gets in the way of cleaning up and evolving nix-darwin, because of the numerous versions of Nixpkgs that must be handled simultaneously and the fact that any breaking change immediately hits the entire user base.
From my experience, and what I have heard from nix-darwin users, I think that having Nixpkgs-matching release branches would make things easier for both users and maintainers, and I plan to write up a more detailed proposal about the benefits and how we could go about achieving it with minimal maintainer effort (probably less effort overall than working around the lack of release branches causes now). There's a reason that NixOS is tied to its Nixpkgs version and that Home Manager also branches off in sync; I strongly believe that we should do the same and would be happy to devote effort to working out process and implementation for this.
(I also think it would be good to have more extensive testing and maybe at some point we could even have a working VM-based test setup. But that would probably be a lot of work to integrate into CI given complications with macOS licensing and simultaneous VM limits, and hard to get infrastructure for given that most macOS CI providers will already be running in a VM and nested virtualization is hard; maybe we could get a free Mac server through MacStadium's FOSS programs or similar though.)
@Enzime I would like to nominate myself and @emilazy as maintainers for nix-darwin, as we have both been actively contributing to the repository in recent history: https://github.com/LnL7/nix-darwin/graphs/contributors
Great, you've certainly both made some more than trivial changes.
Thank you! I will do my best :)
Thank you @emilazy for the cleanup! I really appreciate it
but I'm interested in bringing nix-darwin into closer alignment and compatibility with NixOS
Speaking of compatibility with NixOS, should we make that an explicit goal of nix-darwin?
I think that "when the same option is present in both NixOS and nix-darwin and their types overlap, they should behave the same way" should definitely be a goal, and nix-darwin already largely adheres to it. It's basically the bare minimum to be able to share any modules or configuration between both.
Complete compatibility is infeasible, of course, due to things like Linux- and systemd-specific options. I personally think that goals like "we should reuse/track as much of upstream NixOS modules/tools as is practical unless they would require major surgery to work" and "we should generally follow NixOS's internal structure unless it doesn't make sense due to our differences or we can do better" are valuable, but they are stronger than the weaker goal I think we can all agree on.
I think that "when the same option is present in both NixOS and nix-darwin and their types overlap, they should behave the same way" should definitely be a goal, and nix-darwin already largely adheres to it. It's basically the bare minimum to be able to share any modules or configuration between both.
Complete compatibility is infeasible, of course, due to things like Linux- and systemd-specific options. I personally think that goals like "we should reuse/track as much of upstream NixOS modules/tools as is practical unless they would require major surgery to work" and "we should generally follow NixOS's internal structure unless it doesn't make sense due to our differences or we can do better" are valuable, but they are stronger than the weaker goal I think we can all agree on.
I agree with this notion. At one time, I suggested to lnl7 that nix-darwin should be merged with the upstream nixos/nixpkgs repository in order to facilitate compatibility between the two. If I recall correctly (it's probably been around two years), he thought that by doing we would open up MacOS users of nix-darwin to potentially bricked machines -- he was worried that you could brick a macos system but inadvertently affecting the configuration of a darwin component when editing a nixos component.