You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
# 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.
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 useinherit(flake-schemas.schemas)descriptioninputsschemas;outputs={# get the schemas for the `outputs` attributes we useinherit(flake-schemas.schemas.outputs)overlayspackagesschemas;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
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. ↩
The text was updated successfully, but these errors were encountered:
As @edolstra says here
flake-schemas/flake.nix
Line 214 in 7649320
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, butschemas = 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.
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.Footnotes
I would suggest that @lheckemann’s proposal be split similarly to this one – an
outputs.options
to define options and a top-leveloptions
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. ↩The text was updated successfully, but these errors were encountered: