Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

distinguish between defined & used schemas #13

Open
sellout opened this issue Oct 20, 2023 · 0 comments
Open

distinguish between defined & used schemas #13

sellout opened this issue Oct 20, 2023 · 0 comments

Comments

@sellout
Copy link
Contributor

sellout commented Oct 20, 2023

As @edolstra says here

# FIXME: distinguish between available and active schemas?

it would be great to be able to define schemas distinct from the set of schemas used by the flake. Partially because you might not want to use all the schemas you define, but more significantly, you don’t want to re-export the upstream schemas you’re using, as then schemas = nix-darwin.schemas // home-manager.schemas; would incidentally provide you with the “base” schemas, but not necessarily the versions of them that you expected. As schemas get more widely adopted, you’re forcing the user to topo-sort the inputs that provide schemas. E.g., schemas = nix-darwin.schemas // home-manager.schemas // flake-schemas.schemas; does the right thing, but schemas = flake-schemas.schemas // nix-darwin.schemas // home-manager.schemas; does not.

My proposal would be to have the existing outputs.schemas be the schema definitions – these are schemas that are output by the flake. Then a top-level attribute, schemas would be the schemas used by the flake.

The complication of this approach is that you need to apply schemas not just to the outputs, but to the top-level attrset. The current flake schemas become “output schemas”, and the schemas proposed here would be able to affect elements outside of outputs.

Another use case for this generalization is options as in @lheckemann’s NixCon talk1.

Here’s an example flake trying to show how I think this might look/work.

{
  description = "schema example";

  inputs.flake-schemas.url = "github:DeterminateSystems/flake-schemas";

  # This takes `inputs` (like `outputs` does), but it also takes `outputs` to be able to find locally-defined schemas.
  schemas = {flake-schemas, ...}: outputs: {
    # get the schemas for the top-level attributes we use
    inherit (flake-schemas.schemas) description inputs schemas;
    outputs = {
      # get the schemas for the `outputs` attributes we use
      inherit (flake-schemas.schemas.outputs) overlays packages schemas;
      inherit (outputs.schemas.outputs) myNewOutputs;
      myPrivateOutputs = {
        version = 1;
        doc = "An output whose schema isn’t available elsewhere.";
        inventory = flake-schemas.lib.derivationsInventory "myPrivateOutputs" false;
      };
    };
  };

  outputs = {flake-schemas, ...}: {
    overlays.default = final: prev: {};
    packages = {};
    schemas.outputs.myNewOutputs = {
      version = 1;
      doc = "An output whose schema is published by this flake.";
      inventory = flake-schemas.lib.derivationsInventory "myNewOutputs" false;
    };
  };
}

The top-level schemas attribute in this case could be simplified to something like the following, if you don’t want to restrict to exactly the schemas you’re using.

  schemas = flake-schemas.schemas // {
    outputs = flake-schemas.schemas.outputs // outputs.schemas.outputs // {
      myPrivateOutputs = {
        version = 1;
        doc = "An output whose schema isn’t available elsewhere.";
        inventory = flake-schemas.lib.derivationsInventory "myPrivateOutputs" false;
      };
    };
  };

Footnotes

  1. I would suggest that @lheckemann’s proposal be split similarly to this one – an outputs.options to define options and a top-level options for ones available to the flake. This would also eliminate the need for the manual namespacing (like "org.nixos.nixpgs.config"), since normal flake references would serve the same purpose.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant