Hi all, just getting started with YGOT, thanks for your continued investment in this project over time! I was going to comment on #412 as it discusses consumers of the public APIs, but created an issue as I realized there are more data points I wanted to reference for clarity.

Our use case is to feed the generated structs for a YANG schema into Kubebuilder. The composition of these types would open up a lot of options for disaggregated control plane options! So far, generation using include_schema=false to a single file creates structs that can be manually aggregated into very usable Kubernetes custom resources.

In its parse, Kubebuilder captures object and field comments, field names and types, struct tags and other aspects to generate additional metadata. To generate a CRD, these are restructured into OpenAPI v3 schemas in a form that they call a "structural schema". It's all very specific to Kubernetes and Kubebuilder, but it's our top candidate at the moment for the developer UX of the overall solution.

What I had hoped to find in YGOT / ygen is the template definitions were somehow modifiable, but they are statically defined as private local variables.

A couple of solutions come to mind, the obvious one is to make access to these templates public and override the class, but that would make overrides brittle to future change. At the other extreme, it's not DRY to duplicate the entire generator except on a fork, which we'd like to avoid.

I am probably missing a lot of context here, so wanted to get feedback if @wenovus or @robshakir had time to consider it. Another concern is the tag setting code, which we need to add YAML serialization tags and the model description attributes, which aren't a part of the typical Go template context. The template contexts could be made larger, but at a cost of maintainer confusion for unused data. It would work if the IR exposed yang.Entry (even if the internal generators didn't use it).

If we were to generate a PR, what kinds of objectives might reviewers be looking for leading to a successful merge? Of course there are many options and we don't want to create a lot of work on your end – or end up with an unintentional fork on our end. There's no guarantees (as in life), just discovering options that are a good fit with general community constraints. Thanks!