`std` output schema

[blaggacao]

Would the divnix/std deliberate, but useful output schema be in scope for garnix?

In turn I could implement std support.

https://github.com/divnix/std

Better docs being worked on.

For now, just hit the repl in the root and see how it works.

A metadata contract can be exposed on outputs.__std, if necessary.

[jkarni]

Hey! std looks interesting! My understanding is that rather than the packages, checks, etc. attributes, other attributes are used (runnables, installables, etc)? And the question is how we can get garnix and that schema to play well together?

[blaggacao]

And the question is how we can get garnix and that schema to play well together?

The schema is entirely user defined (<system>.<cellname>.<organellename>.<target>), but fortunately output.__std.<system>.init cheaply evaluates to the metadata information that answer's the question about "what's in this flake?".

I think one prerequisite is to formally stabilize the outputs.__std.<system>.init interface so that it may be consumed by 3rd parties, as well.

I don't think it may change massively at this point, but maybe waiting for a 1.0 might be still wise (and an incentive to stabilize GA 1.0). :smile:

[blaggacao]

Standard shortly introduces conceptually "The Registry" (json-serializable data under .#__std).

That registry already contains several registers, currently used for feeding data into the TUI.

Soon, I want to include a __std.ci register with three phases:

• __std.ci.lint = [ {} ];
• __std.ci.build = [ {} ];
• __std.ci.deploy = [ {} ];

So, now I've got two options for us (you and me) to choose from:

• Standard, via Nixago, renders garnix.yaml (need to learn Nixago)
• Garnix reads out these registers and does it's thing. (ootb experience)

Note: attrsets can be parallelized, lists imply sequenciality.

[jkarni]

This is no longer planned. If the majority of the community moves to std, we'll reconsider.