To make sure that I get everything right, I built this code for
initializing the equipment library around the already existing JSON IO
loader. That is far from optimal because there is no type safety
whatsoever in these classes, and object properties are created in a
super ad-hoc manner at runtime. That is rather painful to work with
because there is no place anywhere in the code which would list all
properties that are *supposed* to be present.
Change-Id: Ibbfd97a5a949cf107fd98484b19b24bf9f4ca3e9
I'm using the yagnson library for this, and that library needs two
pieces of data as its inputs:
- a "YANG Module Library", which is usually a JSON description of all
available and activated YANG modules along its enabled features, etc,
- actual YANG models, typically specified as a list of filesystem paths
which hold them.
I generated that ietf-yanglib file via something like:
$ python path/to/yangson/tools/python/mkylib.py \
gnpy/yang/ext \
gnpy/yang/tip \
> gnpy/yang/yanglib.json`
When this adds support for `ietf-geo-location` in future, make sure to
edit the output so that it does not accidentally enable all of the
geolocation features (but that's for later, anyway). And we might
actually not end up doing that.
Change-Id: I51e342cd556ecc381ff0bf35df2bfa70f5f83ba8
I'm using a second-level module namespace (gnpy.yang) for the same
reasons as when shipping the example data via gnpy/example-data/ --
these will be used in the subsequent commits when we actually start
adding YANG models. There is also some code (not much now, a lot more in
future) for working with these models, and in future also for loading
actual data. These *could* be put into gnpy.tools.*, but I think it's
more straightforward to just keep them in the YANG namespace.
Change-Id: Ic40738ddd8346429bde01e591d19fd2ce8cb687d
