Add the Magic Nix Cache as an option to the GitHub Actions page

[grahamc]

Not sure if this is the right place for it, but it seemed like the most direct place to add it. I'm open to other suggestions as well.

[infinisil]

While it's always a bit of a question how much we should document third-party projects in the official docs, considering that Cachix is already there only makes it fair to also have the Magic Nix Cache. So I think it's okay to have this.

But, would you also be interested in making the Magic Nix Cache official? That would definitely be my preference, similar to how nix.dev itself became official.

[grahamc]

Thanks for the review. We're not interested in upstreaming / donating Magic Nix Cache at this time, but we could revisit in the future. It is fully open source though (Apache 2.0) so if the NixOS org wanted to fork it and give it a new name, that is perfectly within its rights! I am glad to see that nix.dev's weird copyright situation was resolved, though :).

[yukiisbored]

While it's always a bit of a question how much we should document third-party projects in the official docs, considering that Cachix is already there only makes it fair to also have the Magic Nix Cache. So I think it's okay to have this.

I think we should have a policy on third-party projects in nix.dev since IMO not mentioning them will only do more harm than good.

[asymmetric]

I believe we do have a policy, and it's that we don't cover third-party projects. Cachix being there seems to be a historical artifact, so I'm not sure how we should act here.

On the one hand, if I'm correct about the policy, we should remove it.
On the other, this might do a disservice to our readers, as Cachix is a very widely used piece of infrastructure. But then so are flakes, so that's a slippery slope argument, I suppose 🤡

So it seems that the most coherent thing to do would be to remove the Cachix tutorial entirely, and close this PR, but I'm not sure if it's also the correct thing to do.

[infinisil]

I don't think we made a decision on any policy yet. But If we had to, I think it should be that we should point out useful and commonly used third-party projects with at least a mention and some basic description, without going in-depth (the third-party docs are there for that). As you say, it would be a disservice to not mention such projects, they're clearly useful.

[grahamc]

On the other, this might do a disservice to our readers, as Cachix is a very widely used piece of infrastructure. But then so are flakes, so that's a slippery slope argument, I suppose 🤡

While I think it is a mistake to exclude third party FOSS, and third party proprietary software that is in available in and from the community, I don't think this is a valid comparison to make as flakes are first party software.

Note that adopting a restrictive / prohibitive policy regarding third party projects would impact other useful and valuable material as well:

• The Nix Hour
• NixOS Wiki
• These tools for bootstrapping NixOS:
  • https://github.com/jeaye/nixos-in-place
  • https://github.com/elitak/nixos-infect
  • https://github.com/cleverca22/nix-tests/tree/master/kexec
• the nix-dot-dev organization
• references to nix-community like direnv, nix-index
• other tools, like: niv, hercules ci, and the terraform-nixos terraform module from tweag,
• other great documentation sources like the nix one-pager from tazjin, and the nixcloud tour of nix.

There are others as well. I think the best approach here is to be expansive of what is reasonable and useful, and not try to cut out parts of the community because of a notion of first party-ness, which is hard to define when we're discussing a community. Some people will be interested in FOSS options, some will be interested in proprietary options, some will be interested in costly and highly restricted licensed options too, and the way I see it they're all valid participants in the community and we're all better off for it.

[proofconstruction]

I think we should have a policy on third-party projects in nix.dev since IMO not mentioning them will only do more harm than good.

Agreed, and this is really part of the broader discussion around the degree of integration (or at least cross-linking) between the core Nix projects and 3rd party tools.

For now, it seems unfair for only Cachix to get mention here, but we also discuss using Niv in the tutorial on pinning Nixpkgs, using Terraform to deploy NixOS etc, so the problem is bigger than this page.

Now that nix.dev is official, I would rather see no 3rd party tools whatsoever than let this particular space of learning serve double duty advertising for other projects.

That said, I also feel strongly that there should be some mention of these somewhere "official", at least because these tools are useful to many, but also because the standing policy of not documenting stuff people actually use today is leading to wide fragmentation of the documentation ecosystem, which harms uptake by newcomers, deeper understanding by folks already here, and needlessly duplicates effort.

A good compromise might be:

1. merge this for now
2. provisionally, write a page explaining that we only mention unofficial tools on nix.dev to provide utility to the userbase, and we do not and cannot maintain tools outside of the NixOS GitHub org, at least as part of our responsibilities on the docs team
3. discuss further policy directions with the community on Discord Discourse, at NixCon, etc

[zmitchell]

I've approved this for now in lieu of a clear policy, but I think there's a distinction to be made regarding third-party FOSS tools and third-party commercial tools. Discussing an open source tool in our tutorials is one thing, free advertising for a commercial product is a different thing.

I think Cachix is only listed for historical reasons, and I would personally be fine removing it now that this site is official.

[grahamc]

I think there's a distinction to be made regarding third-party FOSS tools and third-party commercial tools. Discussing an open source tool in our tutorials is one thing, free advertising for a commercial product is a different thing.

This is an interesting perspective, and I think is worth exploring more.
My perspective is FOSS and commercial aren't opposing positions, but that there are FOSS and proprietary, and commercial and non-commercial.

For example, the Magic Nix Cache is FOSS, licensed with OSI approved licenses: Apache 2.0 (the CLI) and MIT (the action.) Similarly, I believe the Cachix CLI, API client, and GitHub action are all Apache 2.0.

The comparison continues in an interesting fashion. Cachix client isn't usable without a proprietary service - Cachix.org. This is also true for the Magic Nix Cache, which depends on a proprietary service - the GitHub Actions cache interface. Both of these have a free tier, considerations for open source, and also a monetization strategy. For the Magic Nix Cache, people using helps our business by demonstrating that we solve users' problems.

This prompts a few questions for me:

• Should the nix.dev project be forced to give up on Cachix, and its GitHub actions?
• Is the problem that the projects are hosted under a commercial entity's GitHub organization?
• Would projects under our personal accounts be suspect, even though those likely have something to do with our work?
• Is it wrong to try and solve users' problems and ask for money in exchange?

We're all here to get something out of the project, be it a feeling of belonging, reliable infrastructure, a stable career, developing our skills, a profitable business, etc. I think for this project to be successful, we need to be honest and up front about our motivations, what we're each trying to get out of it, and what our goals are.

This isn't to demonize Cachix or Domen or argue that Cachix should go and my thing should stay, quite the opposite. Cachix is an important and valuable tool, and it is a benefit to show Nix's users how to have a great experience when a binary cache will offer great benefits. I feel not discussing Cachix (and alternatives!) is a disservice to Nix's users and ecosystem at large.

[proofconstruction]

Strong agreement with this:

for this project to be successful, we need to be honest and up front about our motivations, what we're each trying to get out of it, and what our goals are.

I have some notes on all of this (addressing those questions, musings on licensing, what stance the official projects - particularly docs - should take re: 3rd-party and first-party-unstable solutions, etc.) which I'll share for editing & discussion soon.

For now, I think there's enough agreement to merge this with these few minor changes.

[grahamc]

Thanks for the edits, @proofconstruction!

[zmitchell]

This is an interesting perspective, and I think is worth exploring more.

Sure, my main point is that (personally) promoting third-party FOSS tools like niv, nix-locate, etc are an obvious "yes", and the commercial/proprietary tools are a "maybe?" that warrants more discussion.