Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add pyang --schema-from-path option #524

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

remingtonc
Copy link
Contributor

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.

@coveralls
Copy link

Coverage Status

Coverage remained the same at ?% when pulling c52d5da on cisco-ie:schema-from-path into bf0bf09 on mbj4668:master.

@coveralls
Copy link

coveralls commented Nov 23, 2019

Coverage Status

Coverage remained the same at ?% when pulling d173ab8 on cisco-ie:schema-from-path into bf0bf09 on mbj4668:master.

bin/pyang Outdated Show resolved Hide resolved
bin/pyang Outdated Show resolved Hide resolved
@mbj4668
Copy link
Owner

mbj4668 commented Nov 25, 2019

I understand what this option does, but what is the use case?

@remingtonc
Copy link
Contributor Author

remingtonc commented Nov 25, 2019

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.

@remingtonc
Copy link
Contributor Author

remingtonc commented Nov 26, 2019

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"

@mbj4668
Copy link
Owner

mbj4668 commented Nov 26, 2019

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.

@remingtonc
Copy link
Contributor Author

remingtonc commented Dec 2, 2019

This option is still useful as is. There are workarounds, e.g. emptying the default directories. I'm fine with either option:

  1. Gating this option until the directory specification for modules is more robust.
  2. As-is functionality reviewed, separate issue for the module intelligence.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants