Transition manual from 3.x to 4.0?

[steweg]

Hi,

as I noticed that libyang was already moved to version 4.0.X, is there a transition manual? I am working with libyang-python project, which is still using version 3.X, and I would like to prepare PR, which will allow using version 4.0.X. But without the manual it is quite hard to asses the needed changes by ourselves.

Something similar to https://netopeer.liberouter.org/doc/libyang/master/html/transition2_3.html would be very nice

Thanks

[michalvasko]

It is exactly where one would expect it to be but in the devel branch, for now, naturally. Here is the link. There are not many obvious API changes (which are easiest to cover, anyway) so there is no table with the changes as before but the important parts should be mentioned in the text.

[steweg]

Thanks

[steweg]

Hi,

I am reopening this to get one clarification. I have made successfully the first draft of libyang-python adjustments to use v4. But there is one issue, which I am little bit struggling with. Previously the leaf default or leaf-list defaults were represented in compiled schema as data node. Now they are represented only as dedicated structure with string representation. This is sufficient for basic holding of value itself in string format. Unfortunately the side-effect is that in python the library relied on getting realtype associated with lyd_value to properly convert string value to python types (e.g. to boolean, integer, float...). Now this is not possible and we can only guess the realtype based on type of leaf/leaf-list. But in case of leafref or union types that it really just guessing. To mitigate that I can create new lyd_term_node with given value and read that from there and free the node for good. But it seems to be quite overkill to do that everytime user would like to get default value with correct type.

So I was wondering if there would not be any other suitable way how to simply get final resolved type of default value?

Thanks

[michalvasko]

Right, you are not the first user to have questions regarding this change so I have made some (hopefully final) changes and added function lyd_value_validate_dflt() for this purpose. But note that it internally does pretty much the same work as you did, stores and validates the value. There is no other way to correctly perform this and this information can no longer be stored in the context (hence the change).

[steweg]

Thanks, that really helps at least libyang-python project.