Mandatory module name in the generated struct names

[hellt]

Hi @wenovus @robshakir I had a quick look into the generator options but couldn't find an option to disable prefixing generated structs/fields with the module name.

Consider me having a simple module in test.yang file that goes like

module test {
  yang-version 1.1;
  namespace "urn:srlinux:ndk:test";
  prefix srl-labs;

  container app {
    leaf name {
      type string;
    }
  }
}

the generate struct would have:

// Test_App represents the /test/app YANG schema element.
type Test_App struct {
    Name    *string `path:"name" module:"test"`
}

and I wonder if there is a way to disable prefixing the yang elements with the module name?

PS. And is // Test_App represents the /test/app YANG schema element. comment really correct in that case? I have no /test element in my yang, I happened to name the module that way, but does it bear any difference in broader view for the yang schema locator?

PS2. what I wanted to have is

// App represents the /app YANG schema element.
type App struct {
    Name    *string `path:"name" module:"test"`
}

[wenovus]

Hi @hellt, the code for creating the name is at https://github.com/openconfig/ygot/blob/master/gogen/goelements.go#L239

To change it you can add a new generation option and flag that would exclude the module name in the generated name.

I believe the reason it was originally included is because multiple modules can conflict. But if there is no reason to expect a conflict of top-level nodes in your YANG modules, then this would make sense. This was the decision for "compressed" generated code, so you can borrow the logic used there: https://github.com/openconfig/ygot/blob/4dcc65ef1230778675d989ce9a4d194512974f17/util/yang.go#L178-L180

[robshakir]

Wen is right here -- in goyang we build a tree per-module by creating a top-level entity named after the module's name -- the issue otherwise is that if you have ietf-interfaces and openconfig-interfaces on the same build then they would conflict.

[hellt]

Thank you, I will have a look at adding a generator option to cater for smaller YANG code bases where non interfering top level containers are the norm.

In the meantime I will close the issue, as the questions has been answered.