Fediversity Panel

Flake attributes

The flake outputs the panel entrypoint (./panel#...) exposes. This page is generated from the entrypoint itself every time the docs are built, so it always reflects the current outputs. Descriptions come from each attribute's meta.description.

Two kinds of attribute

The generated lists at the end of this page are panel/'s own leaf outputs: the Django package, the forms-island bundle, the generated openapi-client, the checks. They are not the whole of ./panel#.

Alongside them the entrypoint carries a deploy family: a full set of <group>-<effect>-<machine> attributes that provision the hosting-provider machines with BOTH the api and panel services registered. This is the full mono-repo composition, and the repo-root default.nix re-exports exactly this family as its top-level deploy attributes (with the authoritative whole-repo pin baked in). So at the repository root:

nix run '.#<group>-<effect>-<machine>'   # resolves to panel's deploy family

or against the leaf directly:

nix run './panel#apps.<group>-<effect>-<machine>'

How the two sets combine:

  • apps, nixosConfigurations and deploymentAttributeNames come verbatim from the rendered deploy family.
  • packages and devShells are deploy.<x> // <panel's own>, so panel/'s leaf attributes win. The deploy names are all group- and effect-prefixed, so they sit alongside the flat leaf names without collision; the single overlap is devShells.default, which stays the panel devShell.

The names follow core's grammar

panel/ does not invent attribute names: they follow core's <group>-<effect>-<machine>[-<verb>] grammar exactly, described at https://core.pages.git.fediversity.eu/flake-attributes.html. The derivations differ, because this family is rendered from a group set that has both api/ and panel/ folded in, but the naming, the all/combined aggregate targets and the verbs are the same. They are not enumerated here: the family is on the order of a thousand attributes, and core's page documents the pattern rather than the list. For the flat enumeration:

nix eval --json ./panel#deploymentAttributeNames

How it is built (and how to extend it)

panel/ maintains no deployment topology of its own. It reuses core's pure render combinator. Rather than re-fold api's application onto the frontend-free base itself, panel/ extends api's pre-extended group (api.lib.composedGroups, which is base + api's application) with only its OWN application, then re-renders:

core = import ../core { inherit system sources pkgs; };
apiLeaf = import ../api { inherit system sources pkgs; };
composedGroups = core.lib.foldGroupComponents apiLeaf.lib.composedGroups {
  hosting-provider = [ component ];  # panel's own fragment only
};
deploy = core.lib.render { inherit system sources groups = composedGroups; };

core is downward-only (it never names a front-end leaf), so this fold happens in the leaf, by name (panel -> api -> core, acyclic). foldGroupComponents appends, so folding [panel] onto api's already-[...base, api] group reproduces the exact [...base, api, panel] merge order -- hence a byte-identical deploy -- that a single [api, panel] fold produced.

A downstream extends the model the same way -- onto api.lib.composedGroups to keep api/ registered, or onto core.lib.baseGroups to stay api-independent. No fork of core. Both routes are spelled out at https://api.pages.git.fediversity.eu/flake-attributes.html.

Packages

  • default
  • docs
  • docs-with-screenshots
  • manage
  • openapi-client: Generated Python client for the fediversity-api HTTP surface
  • screenshots

Checks

  • apps-panel: Deploy applications through the panel web UI and verify the result.
  • panel-basic: Smoke-test the operator panel (Django) boots and serves.
  • panel-docs
  • panel-migrations: Check the panel's Django migrations are complete and apply cleanly.
  • panel-python-tests: Run the panel's Django test suite against sqlite, with no VM.
  • panel-screenshots: Capture the documentation screenshots from the panel web UI.
  • treefmt: Check that the project tree is formatted