This is great. Nix maintainers already decided to help the DS installer get closer to official, and we’re still ready help with getting PRs in that direction merged. Following the NixCon discussion on establishing process to make projects official, a reasonable first step would be to have the repo or a fork in nix-community, where experimental features are disabled and telemetry is removed. (I think we should loosen the requirement to fix up the Bash installer, in hindsight it sounds unreasonably expensive and pointless.)
We all care about usage statistics, but they should be public. Exposing traffic data on the official domains and the cache more systematically would help many people in the ecosystem. @zimbatm what’s the state of affairs on metrics in the infra team? Is there something specific people could help out with?
a reasonable first step would be to have the repo or a fork in
nix-community
We already have a fork in the NixOS org: GitHub - NixOS/experimental-nix-installer: An experimental fork of the Determinate Nix Installer to explore upstreaming.
However, it’s not being built/published yet. People interested in helping out are welcome to join the two-weekly Nix installer workgroup meeting (see the NixOS.org calendar).
Thanks, @fricklerhandwerk! Yep, it’d be great for Nix to be using our installer. AS we said in our initial post, we intentionally licensed it to be easy to do. There’s been a bit of activity on GitHub - NixOS/experimental-nix-installer: An experimental fork of the Determinate Nix Installer to explore upstreaming. which is great to see.
Maybe we should follow the clear consensus we obtained and move it to nix-community until the experiment is concluded?
Hrm. I don’t feel like we received clear consensus, but I’d be very glad to be wrong. Why should it move to nix-community? My impression is that organization is effectively unrelated to the NixOS Foundation and Nix project beyond being a great place for community projects. Why would it / what’s the advantage for it to move?
Where can I find this calendar? I really tried my best to find it, but the only thing I found was the Community Calendar.
FWIW, I also have an implementation of the other way around this problem (for the official installer, but the approach should be viable for either if it holds water).
@ifreilicht has helped validate the broad strokes and identified a small fix, so I should be able to open a PR after applying it.
I don’t think either approach is quite ideal, so having an implementation of both should give us a chance to understand which works best in the wild.
Here’s the PR mentioned above: darwin-installer: work around zshrc overwrites by abathur · Pull Request #9243 · NixOS/nix · GitHub
The two approaches are quite different. I went ahead and described both in the context section, and also included a note on how you can test it.
I meant consensus on having projects at roughly that level of support and general acceptance in nix-community. It seems there was no objection to the proposed criteria so far, and we made quite an effort to ask everyone who may care and have an influence on the outcome. That’s as much of a clear consensus as we usually get around here.
To signal its support status. The forked installer is not the official one, so it should not be an official project under the NixOS GitHub org. It seems that currently only @abathur is maintaining it, so it is actively maintained, which qualifies for nix-community. Placing it on the same level as say Nix and Nixpkgs would only add to the type of mixed signals and associated uncertainty the ecosystem has been suffering for a number of years, such as with flakes and the user wiki. That situation is really not great for fostering broader adoption.
I’m puzzled by this statement. Yes, it’s in a sense unrelated to the NixOS Foundation, so what? Almost everything is. All the foundation is supposed to do is keep the lights on and take care that the brand is not abused. On the other hand, @zimbatm is one of the owners for both nix-community GitHub org and NixOS GitHub org, and lots of nix-community maintainers are also highly active contributors to projects in the NixOS GitHub org. So they are objectively quite related. What exactly that means and what the “Nix project” is supposed to be, is still to be defined, to the best of my knowledge. That’s indeed one of the motivating questions of the governance discussions. I suggest we continue in that thread.
Here’s my perception of the ~problems, based on experience and interpretation of discussions in installer WG meetings at which multiple Nix team members were present:
- the project tends to be pretty conservative about changes to the installer (it’s high stakes, and everyone’s afraid of breaking it)
- the Nix team is interested in adopting something based on the detsys installer, but they do want substantive changes
- Nix team representatives were clear enough that they aren’t going to do the work to ~pull the detsys installer and implement these changes
- the detsys team is clear that they want this to be pulled from the Nix side, and not something they push
I don’t really want ownership of the new installer, but I could feel the gravity of this situation pulling us towards a stalemate, so I tried to refocus discussion around the smallest bites that might get the effort back on track towards adoption.
The ~goal we agreed on at that time was working towards an “official experimental” installer. Basically, this means figuring out and executing on:
- Building the installer.
- Applying the non-negotiable changes that the Nix team wants.
- Working out what we need to publish the installer.
- Getting the installer published on nixos.org in a way that clearly indicates both that it is experimental, but that is an official experiment. I.e., it isn’t Crazy Bob’s experimental Nix installer.
- Working to build the confidence the team will need to pull the trigger on adoption by selectively recommending the “official experimental” installer to community regulars and people who present with official-official installer problems.
The next-to-last item is probably my fault.
I do a large fraction of the installer troubleshooting/support in Nix issues (and sometimes discourse), and I’m personally not comfortable making broad public recommendations to try third-party installers in either of these official spaces. I occasionally recommend a PR-specific installer to people when we’re acutely trying to gather information to validate a PR, but this circumstance is quite different.
Given those goals and risk of stalemate, I agreed to take hold of the reins of a fork for long enough to try to get us over these first few hurdles. @mkenigs has done the actual work here. We (@mkenigs and I) were hoping this would be done by now, but we’ve been in a holding pattern for a bit as we waited for some work to land in the detsys repo before we sync up again. IIRC there’s another change or two from there before we should be ~ready to start poking people with keys about what’s needed to start publishing it.