Open Stack

On 05/10/2018 05:01 PM, Stefano Canepa wrote:
> 
> On 10 May 2018 at 10:55, Ilya Etingof <ietingof at redhat.com
> <mailto:ietingof at redhat.com>> wrote:
> 
> 
>     Hi Stefano,
> 
>     The best solution would be of course to fix pysmi code generator [1] to
>     behave. ;-)
> 
> 
> ​This is something that pysmi author already gives for granted in the
> Release notes.
> I bet you know this better then me ;-)​
>  
>  
> 
>     On the other hand, if you won't include the autogenerated code into your
>     package, the code generation would happen just once at run time - the
>     autogenerated module would get cached on the file system and loaded from
>     there ever after.
> 
>     Theoretically, not pinning Python MIB in your package has an advantage
>     of letting pysmi pulling newer ASN.1 MIB and turning it into Python
>     whenever newer MIB revision becomes available.
> 
> 
> ​Ilya you're confusing me. Do you mean that, even if I load my MIB and
> all other it depends on from ASN.1, they are compiled into python byte
> code and cached and blah blah? ​

The workflow is this:

* pysnmp wants to load a MY-MIB by name (e.g. evaluate the contents of
MY-MIB.py, turn it into Python objects and link them up to its in-memory
MIB tree)
* pysnmp searches for MY-MIB.py[co] in its search path
* if pysnmp is successful, we are done
* if pysnmp does not find MY-MIB.py[co] and pysmi package is present,
pysnmp calls pysmi with MY-MIB name on input
* pysmi tries to find MY-MIB (e.g. in ASN.1 form) in its search path
(possibly including remote locations), compile it into MY-MIB.py[co] and
cache it somewhere within pysnmp search path
* if pysmi is successful, pysnmp starts over loading MY-MIB.py[co]

Hope this is helpful. ;)