fosrl-badger: init at 1.2.0

[jackrosenberg]

Things done

Dependency for pangolin. This allows us to version the traefik plugin.

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

---

Add a 👍 reaction to pull requests you find important.

[jackrosenberg]

@adamcstephens #416148 (comment)

[SigmaSquadron]

@ofborg eval

[adamcstephens]

How do you plan to use this with traefik? I'm wondering if we should start a pattern of traefikPlugins since these are all just sources. I've got another plugin I've started using that could go there too. e.g. maybe it's best to build the infrastructure for declarative plugin management with nix provided sources?

[jackrosenberg]

How do you plan to use this with traefik? I'm wondering if we should start a pattern of traefikPlugins since these are all just sources. I've got another plugin I've started using that could go there too. e.g. maybe it's best to build the infrastructure for declarative plugin management with nix provided sources?

I'm currently working on implementing something like this: https://community.traefik.io/t/how-to-install-run-plugin-from-file-offline/23597/2, which IMO would be a much better way to manage traefik plugins overall. This way we can pull traefik plugins into the Nix ecosystem and manage the versions declaratively.

Edit:
Also, since each package knows its <plugin owner> (via pkgs.<name>.owner), we can make the correct folder structure in traefik.

[SigmaSquadron]

How do you plan to use this with traefik? I'm wondering if we should start a pattern of traefikPlugins since these are all just sources. I've got another plugin I've started using that could go there too. e.g. maybe it's best to build the infrastructure for declarative plugin management with nix provided sources?

I'm doing that as well. I've opened the wip-traefik-plugins branch so we can all push to it and then merge into master when we're done.

[SigmaSquadron]

we should start a pattern of traefikPlugins

Do you mean a package set like pythonPackages and friends? I guess we could, but then we'd lose the advantages of by-name.

[adamcstephens]

I was thinking a package set with automation based on a simple list of plugins. Not sure by-name is buying us much here. I would look at other package sets such as Grafana plugins, neovim, or maybe terraform for example, and maybe not the complexity of the Python set. :)

[SigmaSquadron]

The final design would be something like this.

{
  lib,
  fetchTraefikPlugin,
}:

fetchTraefikPlugin {
  plugin = "badger";
  owner = "fosrl";
  version = "1.2.0";
  hash = "";

  meta = {
    description = "Traefik plugin that handles authentication for Pangolin resources";
    homepage = "https://plugins.traefik.io/plugins/676da7c6eaa878daeef9c7e9/fossorial-badger";
    license = lib.licenses.mit;
    maintainers = with lib.maintainers; [
      jackr
      sigmasquadron
    ];
  };
}

resolved

[SigmaSquadron]

So, regarding the package set, I'm not particularly opposed to that, but I would prefer if fosrl-badger specifically is in the top-level of pkgs, in order to simplify the definition of the services.badger.package option in the future refactor of the Pangolin module.

[SigmaSquadron]

Merged into #437073 for further testing.