Use-cases of option-type internals

Development
1

I would like to make extensions and improvements on option-types.

Some of those are merged already:

For example lib.types: attrsWith named placeholder by hsjobeki · Pull Request #344216 · NixOS/nixpkgs · GitHub now allows you to give <name> placeholders different values. So you can give your options better names.

Unfortunately some of the improvements require a lot of preparation effort to be non-breaking if anyone relies on the internal attributes. For example one change in the functor.payload caused some breakages in catppuccin/nix.

Also if you have something like a json-schema converter, which is saw a few times. It will very likely depend on option-types internals.

I would like to use this thread to collect links or use-cases of actively maintained projects that require access to option-type internals.

Which then allows us to find a way of stabilizing the interfaces in the long term.

Thanks for any help :heart:

2 Likes
2

Starting with a project that i also help to maintain currently:

Options tree to jsonschema converter:

Depends on:

type.functor.payload
type.nestedTypes.elemType

3

Not sure which parts are internal, but in GitHub - nix-community/flakelight: Framework for simplifying flake setup [maintainer=@accelbread] I use a bunch of custom types.

The type fields I use are name, description, descriptionClass, check, merge, getSubOptions, getSubModules, substSubModules, functor, nestedTypes.coercedType, and nestedTypes.finalType. Might have missed something.

1 Like