Add/remove plugin implemented on-the-fly

[steweg]

Hi,

I my project, we need to define certain YANG extensions (already done), and use those extensions in various places for adjusting UI behavior etc... So far so good. But recently I was asked to provide some sort of validation, which effectively means that I should write extension plugin. That would still be ok, but our project is in python and your API expects to load compiled shared library to load plugin, So that would mean that my project will suddenly need to maintain and distribute somehow shared libraries, which is quite complicated compared to maintain simple python based project, due to need to perform cross-compilations to target platform etc..

So I was wondering whether it would not be better to allow also adding/removing plugins directly by some new API, which will allow users to actually develop the plugin code on the fly in language of their choice and use it within libyang.

Any idea?

[michalvasko]

Not sure I understand what exactly you expect. I can imagine an API that would directly get the plugin struct/callbacks (function pointers) to execute but that would all still be in C. So I do not see a way for libyang to execute any other code than C, if that is what you wanted.

[steweg]

I would like to define my plugin in python completely and extend libyang-python with making a wrapper structures around the API of libyang. Similarly like I did for loading of the modules from remote server, using ly_ctx_set_module_imp_clb. To do that I would add API in libyang like ly_ctx_add_ext_plugin...... I will try to do it end-to-end (including libyang-python), and once I will have, I will open PR, where we can continue discussion about details

[steweg]

Coming back to this topic. I was able to preliminary make it working, but I come to an issue. My extension plugin intention is to under certain conditions, swap the leafref path with another during parse. To do that I would need to be able to call ly_path_parse. That is not public libyang API... So either I will make it public or create another new public API or need to recreate complete parsing logic on my side, for which I would need to completely expose the struct lysp_expr....

To better understand let me give you short example:

module my-ext {
  prefix my-ext;
  namespace "my-ext";;
  extension alt-path { argument "path" }
}

module abc {
  prefix abc;
  namespace "abc";
  import my-ext { prefix my-ext; }
  leaf leaf1 { type string; }
  leaf leaf2 { type string; }
  leaf leaf3 {
    type leafref { path "../leaf1" }
    my-ext:alt-path "../leaf2";
  }
}

Any idea how to achieve this? Thanks

[michalvasko]

There is only so much support for extensions (and I think it is rather comprehensive) and your specific use-case is not. Also, lysp_expr is meant to stay private, there are enough public structures already.

What is supported are nested standard statements. So, either

  leaf leaf3 {
    type leafref { path "../leaf1" }
    my-ext:alt-type {
      path "../leaf2";
    }
  }

or if not then

  leaf leaf3 {
    type leafref { path "../leaf1" }
    my-ext:alt-type {
      type leafref {
        path "../leaf2";
      }
    }
  }

should be automatically parsed into a leafref. Also, if the first case is not supported and you would use it, it can be added easily.

[steweg]

Thanks for help, I was able to do it even with my preferred way using only:

leaf leaf3 {
  type leafref { path "../leaf1"; }
  my-ext:alt-path "../leaf2";
}

To do it my plugin actually emulates creation of child in the same way as if user will define it within the

leaf leaf3 {
  type leafref { path "../leaf1" }
  my-ext:alt-type { type leafref { path "../leaf2"; }}
}

And also by adding substmt in similar manner as you are doing in other extension plugins. It works as it should for me.

Coming back to original question of on-the-fly plugins from memory, I have open PR #2213, which allows given feature I have successfully tested it by using modified version of libyang-python (separate PR is prepared once, PR #2213 will be merged).