Support for multiple model packages of same OS different versions to co-exist

[ganesh-karthick]

User should be able to install multiple model packages of same OS type, but different versions via pip

pip install ydk-models-cisco-ios-xr-6.2.1.tar.gz should not uninstall ydk-models-cisco-ios-xr-6.2.3.tar.gz , they should co-exist in their own python packages , unless otherwise explicitly uninstalled via pip uninstall

This applicable to python libs published in public pypi repo

[psykokwak4]

Currently OS version number is not included in package name, and is used as Python package version number, adding version number to package name might help this issue. Instead of:

$ pip list
Package                            Version
---------------------------------- -------
ydk-models-cisco-ios-xr            6.2.1

The user will get something like:

$ pip list
Package                                  Version
---------------------------------------- -------
ydk-models-cisco-ios-xr-6-2-1            6.2.1  # <-- might also need to change underlying meaning for this version

[manradhaCisco]

So suppose both packages are installed . When you import a module how do you tell it that you want the version of the module from 6.1.1 and not 6.2.1 ? Is that left to the developer ? Or do we plan to add the version number to the module name also??

[111pontes]

Virtualization should be used to support multiple, incompatible versions. Either Python virtual environments or containers. YANG has well-defined backward compatibility rules.

[manradhaCisco]

Suppose I have one python app that talks to multiple OSes each one supporting a backward incompatible version of the same module. In this case the Python VM where the app runs needs to source both packages. But given that they have the same module names, the developer will have to figure out which module needs to be loaded (based on I guess the site where pip installed the package).

[nayyarm]

YDK is not a controller it is yang-dev-kit (API only), it is the responsibility of the developer to feed particular version of set-of-yang models to the generator to produce API for that yang-versions. It is the job of controller-like-software/app to do that for building a real application that deals with multiple platforms involving different versions of models. For such scenario, the App developer would need to see which platform they are communicating and which API is appropriate for them.

In this case, YDK team did produce 611 yang-set based API, here 611 is a platform, not yang-versions. A platform does not support multiple version of same yang model (it is always latest revision), so is the protocol like NETCONF, which work on the unique namespace in the payload.

For two platform release versions, built as two ydk bundles, it would be really like sourcing appropriate module from install location of these bundles within application code.

Given that 1) Adding platform release would give differentiation to bundle installation point location for python bindings.
2) Adding platform release to module-name makes app clumsy especially when several nodes of these modules are compatible across releases and would add maintenance on to App whenever they upgrade to the new release to also include an appropriate module, ven though they don't have any change of business logic (or nodes useage) from that Module.

I see 1 make more sense, where App developer has the power to decide and include an appropriate module on demand. But this does come with the challenge of supporting two bundles (libraries) for C++ bindings, this can be solved too by using dynamic loading support..there is still time to reach this state in C++ stack. So, my vote is 1.

[ghost]

We need to support users who are interested in writing a single python app to work on yang models from different OS versions talking to different OS versions. In theory, we could host multiple versions of ydk-models-cisco-ios-xr bundle as an "archive" of sorts (pip install ydk-models-cisco-ios-xr-611 and pip install ydk-models-cisco-ios-xr-621).

To import these models, users will do something like below

from ydk.models.cisco_ios_xr_621 import Cisco_IOS_XR_ipv4_bgp_cfg as xr_bgp_621

from ydk.models.cisco_ios_xr_611 import Cisco_IOS_XR_ipv4_bgp_cfg as xr_bgp_611

Of course, this "archive" would reside alongside the "mainline" release of the OS bundle, which we keep updating and would work as usual pip install ydk-models-cisco-ios-xr.