On 11 May 2018 at 08:26, Ilya Etingof <ietin...@redhat.com> wrote: > On 05/10/2018 05:01 PM, Stefano Canepa wrote: > > > > On 10 May 2018 at 10:55, Ilya Etingof <ietin...@redhat.com > > <mailto:ietin...@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. ;) >
Super helpful. Copy&pasted this into my notebook for future reference. All the best Stefano
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
