On 05/10/2018 05:01 PM, Stefano Canepa wrote: > > On 10 May 2018 at 10:55, Ilya Etingof <[email protected] > <mailto:[email protected]>> 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. ;) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
