nixops_plugged: attrset of nixops builds, with varying plugin sets included

[deepfire]

Description of changes

As nixops_unstable receives very little maintenance, it's important to keep the remnants working for as many people as possible.

The current nixops_unstable is extremely brittle, as it includes every plugin available -- which means it breaks very easily.

This PR provides an attrset with a bunch of specialised nixops builds, for various backends, as well as the full and minimal options.

This way people can fix whatever plugins they care about and get things rolling, without being forced to deal with plugins they don't care and have no context about.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[roberth]

I have mixed feelings about this, because NixOps isn't subject to a lot of change. Did a plugin break?

[roberth]

This one is commercially supported and is typically used alongside other plugins.

[deepfire]

Note that it's still fully available in nixops_unstable, via nixops_plugged.full.

[deepfire]

I have mixed feelings about this, because NixOps isn't subject to a lot of change. Did a plugin break?

The dependency pins in the forest of plugins are vulnerable to the constant flow of Python dependency changes.

In this case, hetznercloud is the problem, at a minimum -- I've no idea what breaks further, if that's fixed.

[roberth]

That's a fair point about dependencies, I suppose. I don't like the idea of giving up on fixing such plugins, but that's besides the point.

Putting that aside, I don't like any of these packages really. full is similarly anti-modular compared to the other variations. I think we should encourage users to compose their own nixops package from the plugins, even if they're only using one.

Could we make the composition more convenient? I think withPlugins is already pretty good. Maybe it just needs documentation.

[deepfire]

I don't like the idea of giving up on fixing such plugins, but that's besides the point.

Neither do I -- but the point is that the set of people who can fix all the plugins is much smaller than the set of people who can't.

So the status quo is that the rest are essentially prevented from using nixops_unstable -- which I don't think is fair to them.

[deepfire]

Could we make the composition more convenient? I think withPlugins is already pretty good. Maybe it just needs documentation.

If you mean dropping the package set entirely, and mandating the use of withPlugins -- wouldn't that constitute an extra raising of the complexity bar for the end user -- which, I think, would outright be deadly to a project in such a barely-alive state as Nixops..

Or do you mean that we just don't need the full-y plugged version? My point for defining full was that the new scheme ought to express the current nixops_unstable for backward compatibility. It also has a use case for the chivalrous people willing to periodically fix the whole thing : -)

[deepfire]

@roberth, what are your consederations about the PR now, do you think?

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-ready-for-review/3032/3428

[deepfire]

@roberth, a gentle reminder : -)

[roberth]

Thanks. Was just working on #292099, which achieves like 80% of your goal.

It doubles down on

I think we should encourage users to compose their own nixops package from the plugins, even if they're only using one.

[deepfire]

@roberth, that looks great -- closing in favor of #292099

Thank you!