I’m using tailf:annotate, with multiple namespaces and modules.
The first module “uses” a group from the 2nd. Both modules are listed in my import section with prefixes.
In my annotate line, I use the first module’s prefix to specify it, and that works, but when I use the 2nd, it says not found, although it does print the module name it was looking in, and it’s the correct module. pyang validates all the non-annotated yang files without issue.
import module a { prefix p-a; }
// container object a, which has container object b inside, and object b “uses” group that contains object c
import module b { prefix p-b; }
// defines grouping that contains object c
This compiles in pyang:
tailf:annotate /p-a:-object-a/p-a:object-b {
This does not, saying it cannot find object c in the prefix b module.
I tried using pyang --flatten (with various options) to print the xpath with prefixes, but it prints the “top” level prefix for everything, even stuff that’s in a “sub” module.
Is there a way to get pyang to print the xpath in a format that will let me craft the correct xpath for the annotate call?
You can use --flatten-qualified-module-and-prefix-path; I don’t find the output particularly readable, but it uses prefixes everywhere. But pyang is correct in your case: when you do uses grp in the module a, contents of the grouping becomes effectively inlined in your module, so the “model instance” of the container object-c really belongs to a. By uses alone you never get xpaths that need to change the prefix in the middle, you’d have to employ augment for that.
By the way: you may want to use tailf:annotate-module and tailf:annotate-statement instead of tailf:annotate, the two statements address module syntax tree and hence are a bit less confusing.
That explains why it was inserting the “top” prefix everywhere with --flatten-qualified-module-and-prefix-path. I thought was some kind of formatting bug.
I had been using augment previously, and it needed different prefixes all along the xpath, but then I refactored to use uses instead.
It’s not clear how you are compiling, I guess you have something wrong in this: keep in mind that the grouping/uses makes the container part of the module a. So you need to compile the module a with the -a option and the callpoint symbolic name should appear in a's header file (and this is what happens when I test this scenario).
I think I figured it out, I needed to point the -a for compiling module a at the ann file I was using for module b previously, because now it’s “annotating” the path in module a.
I created a very basic test build, and that seems to have worked.