pyang
pyang copied to clipboard
Add pyang --schema-from-path option
Option indicates that pyang
should attempt to load all YANG within the current path instead of desiring a NETCONF hello or explicit filenames.
[pyang] pyang -f tree -p ../oc/release/models --schema-from-path 2>/dev/null | grep module | head -n 10
module: openconfig-access-points
module: openconfig-wifi-phy
module: openconfig-wifi-mac
module: openconfig-ap-manager
module: openconfig-probes
module: openconfig-bfd
module: openconfig-network-instance
module: openconfig-lldp
module: openconfig-qos
module: openconfig-module-catalog
Not certain on correctness of method of loading.
Coverage remained the same at ?% when pulling c52d5daf4d196ba2e948f70a056f54827ac4d3cb on cisco-ie:schema-from-path into bf0bf095dcc45468120bde1b35b73c6f4ad772ea on mbj4668:master.
Coverage remained the same at ?% when pulling d173ab883297c1da277077d875a48bc8320a932d on cisco-ie:schema-from-path into bf0bf095dcc45468120bde1b35b73c6f4ad772ea on mbj4668:master.
I understand what this option does, but what is the use case?
The use case is when we just want to try to fully compile a schema from every YANG module in a base directory and subdirectories. An easy example is the openconfig/public/release/models
path where we may want to compile the schema for the entirety of the directories but would have to otherwise finagle some interesting shell script to do so (AFAIK).
If there's an alternative that easily accomplishes this use case - great! I just couldn't find a simple way to do so.
Edit: due to use_env in FileRepository, have to think about how to appropriately handle. Some of the functionality is nice having ietf types etc, but ideally only modules pulled in by "main" paths modules are actually parsed. Extraneous modules end up in the schema with current implementation.
This might have a bug, getting a bunch of implicit ietf models in the output.
Somewhere IETF models are automatically being pulled into the schema:
.local/share/virtualenvs/pyang-JyL_YjyZ/bin/../share/yang/modules/ietf/ietf-netconf-notifications.yang:288: warning: node "ietf-netconf-notifications::confirm-event" is not found in module "ietf-netconf-notifications"
Ok, I'll wait with this PR until you've had a chance to look at this. I think your idea of adding only modules from the explicit path and others that are pulled in makes sense. Perhaps we can store some info in the module itself about why it is added? Modules added from the explicit paths, and imported would then have this info.
This option is still useful as is. There are workarounds, e.g. emptying the default directories. I'm fine with either option:
- Gating this option until the directory specification for modules is more robust.
- As-is functionality reviewed, separate issue for the module intelligence.