Bug#263417: ITP: pysnmp -- Python implementation of SNMP v.1/v.2c engine
On Mon, 2006-04-24 at 11:37 +0400, Ilya Etingof wrote:
> > v4 contains a mechanism to select the required version before importing
> > pysnmp. So it should be possible to port this mechanism to v2 and v3 and
> > create a pysnmp-common package which contains this module.
>
> If anyone wants to backport this code into pysnmp[23], I'd happily commit
> this into the distros or create a stand-alone package. Otherwise, I can do
> that by myself. Just let me know.
>
> > Of course that would require all users of pysnmp to specifiy the
> > required version.
> >
> > The (imho) cleaner solution would be to use pysnmp[234] as the package
> > names. This sould be coordinated with upstream.
>
> I'm a bit reluctant about this approach because:
>
> 1) It would still require a modification to existing packages (rename
> pysnmp into pysnmp[234])
> 2) Looks like pysnmp4 is going to be final in terms of functionality and
> API (hopefully, oh) so all other versions will be gradually phased out.
> I'd like the final version to be called just "pysnmp" for the sake
> of simplicity and aestetics. ;-)
We could do it like this:
- pysnmp2 is patched to install to pysnmp/v2
- pysnmp3 is patched to install to pysnmp/v3
- pysnmp4 already installs to pysnmp/v4
- the version switch-module from v4 is packaged as pysnmp-common and the
other version depend on it
- Programs need to specify what the need via os.envrion
Perhaps it would be possible to use something like "import pysnmp.v2 as
pysnmp"?
Ilya, the debian-python-team meets in #debian-python on OFTC.
--
Jan Lübbe <jluebbe@lasnet.de> http://sicherheitsschwankung.de
gpg-key 1024D/D8480F2E 2002-03-20
fingerprint 1B25 F91F 9E7B 5D4F 1282 02D6 8A83 8BE4 D848 0F2E
Reply to: