Bug#263417: was Re: Bug#263417: ITP: pysnmp -- Python implementation of SNMP v.1/v.2c engine
Hi there, FYI the latest development versions of PyKota now transparently support both PySNMP v3.4.x and v4.x I was made really easy thanks to the oneliner stuff Ilya added to 4.x : I mostly had to add only 30 lines of code. bye Jerome Alet -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#263417: ITP: pysnmp -- Python implementation of SNMP v.1/v.2c engine
Morten I'm not involved in the packaging of pysnmp, but I guess Morten packaging the 3.x- 4.x-series as separate packages sounds Morten like a good idea if we really want the version 3 and 4 in Morten Debian before upstream freezes their API. I think so too. I have python-pysnmp4 ready, available on the svn repository of debian-python team. I can package pysnmp3 too, but i would like to wait for Jan Luebbe answer about these mails ;). All versions use the pysnmp package name (and therfore the packages conflict against each other), so it would impossible to one package with depends on v2 together with one which depends on v4. Yup, that's a sort of design flaw. I've underestimated the impact of API changes in this project. :-( As an ugly workaround, one could install pysnmp's into different directories and tackle PYTHONPATH on a per-application basis. 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. ;-) -ilya -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 [EMAIL PROTECTED]http://sicherheitsschwankung.de gpg-key 1024D/D8480F2E 2002-03-20 fingerprint 1B25 F91F 9E7B 5D4F 1282 02D6 8A83 8BE4 D848 0F2E
Bug#263417: ITP: pysnmp -- Python implementation of SNMP v.1/v.2c engine
On Mon, Apr 24, 2006 at 02:00:20PM +0200, Jan Lübbe wrote: 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? That would mean that software packaged for Debian which uses pysnmp will have to be patched to be able to use pysnmp, and do we really want that? - Werner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#263417: ITP: pysnmp -- Python implementation of SNMP v.1/v.2c engine
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 Sounds good to me. In terms of the lesser of evils. Perhaps it would be possible to use something like import pysnmp.v2 as pysnmp? Perhaps it depends of how version-switch module works. Even if possible, I'd not suggest this way of version switching (e.g. an API) as it may create another dependency in the future. The os.environ-based method looks functionally the same but it can also be used without source code modifications (e.g. from startup script). -ilya -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#263417: ITP: pysnmp -- Python implementation of SNMP v.1/v.2c engine
On Mon, 2006-04-24 at 14:06 +0200, Morten Werner Olsen wrote: On Mon, Apr 24, 2006 at 02:00:20PM +0200, Jan Lübbe wrote: 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? That would mean that software packaged for Debian which uses pysnmp will have to be patched to be able to use pysnmp, and do we really want that? Its now good, but i dont see any other good way :/ The default (if you don't change os.environ) would be the most recent installed version. But if we don't have a way to select one of the installed version, it would be impossible to install programs that depend on different versions. That would be a severe restriction. What do you think about using the module names pysnmp for pysnmp4 and pysnmp[23] for the older versions? -- Jan Lübbe [EMAIL PROTECTED]http://sicherheitsschwankung.de gpg-key 1024D/D8480F2E 2002-03-20 fingerprint 1B25 F91F 9E7B 5D4F 1282 02D6 8A83 8BE4 D848 0F2E
Bug#263417: ITP: pysnmp -- Python implementation of SNMP v.1/v.2c engine
On Fri, Apr 21, 2006 at 01:11:09AM +0200, Arnaud Fontaine wrote: retitle 263417 ITP: pysnmp -- Python implementation of SNMP v.1/v.2c engine owner 263417 ! thanks Hello, I am interested by packaging this python module. I have already a sponsor. I will prepare a package this week. As mentioned in an earlier post to this bug, the python-pysnmp2 is already uploaded to Debian. Isn't this from the same upstream as your package? From the long package description at least looks like that. If it is, this ITP-bug should probably be closed? - Werner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#263417: ITP: pysnmp -- Python implementation of SNMP v.1/v.2c engine
Morten == Morten Werner Olsen [EMAIL PROTECTED] writes: Morten As mentioned in an earlier post to this bug, the Morten python-pysnmp2 is already uploaded to Debian. Isn't this Morten from the same upstream as your package? From the long Morten package description at least looks like that. If it is, this Morten ITP-bug should probably be closed? The version 2 (stable), 3 and 4 are not compatible (like pykota needs for instance pysnmp 3.x release). Then, maybe we should package each release, what do you think about that ? There is a debian-python team if you are interested. The goal of this team is there [0]. If you want, you can put your packages on the svn repository ;). Regards, Arnaud Fontaine [0] http://python-modules.alioth.debian.org/python-modules-policy.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#263417: ITP: pysnmp -- Python implementation of SNMP v.1/v.2c engine
On Sat, Apr 22, 2006 at 12:55:14PM +0200, Arnaud Fontaine wrote: The version 2 (stable), 3 and 4 are not compatible (like pykota needs for instance pysnmp 3.x release). Then, maybe we should package each release, what do you think about that ? Doesn't the pysnmp 3.x-series have a very unstable API? And is the 3.x-series still under development? I guess the right thing to do is to make sure pykota uses the stable pysnmp 2.x-series until a new stable 4.x-series is ready? I'm not involved in the packaging of pysnmp, but I guess packaging the 3.x- 4.x-series as separate packages sounds like a good idea if we really want the version 3 and 4 in Debian before upstream freezes their API. Jan Luebbe [EMAIL PROTECTED], which is the maintainer for python-pysnmp2, has probably also been thinking about this as he has declared a conflict with python-pysnmp3 and python-pysnmp4 for his python-pysnmp2 package. There is a debian-python team if you are interested. The goal of this team is there [0]. If you want, you can put your packages on the svn repository ;). I'm already a member of this team and plan to move my python packages into the teams SVN-repository. You should probably ask Jan Luebbe if you want to team-main python-pysnmp2, 3 and/or 4 within the Python Modules team [1] on Alioth. - Werner [1] http://python-modules.alioth.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#263417: ITP: pysnmp -- Python implementation of SNMP v.1/v.2c engine
On Sat, 2006-04-22 at 17:24 +0200, Arnaud Fontaine wrote: Morten == Morten Werner Olsen [EMAIL PROTECTED] writes: Morten Doesn't the pysnmp 3.x-series have a very unstable API? And Morten is the 3.x-series still under development? I guess the right Morten thing to do is to make sure pykota uses the stable pysnmp Morten 2.x-series until a new stable 4.x-series is ready? Hello, 3.x-serie and 4.x-serie are unstable releases. Pykota doesn't use the 2.x-serie, only the 3.x-serie. But i think there are many examples of such python applications that use pysnmp2 or pysnmp3 or also pysnmp4, so i thnk that packaging all these branches could be great. I have already packaged version 3 and 4, but they were rejected by the ftp-masters because i did not explain why several versions are needed. Morten I'm not involved in the packaging of pysnmp, but I guess Morten packaging the 3.x- 4.x-series as separate packages sounds Morten like a good idea if we really want the version 3 and 4 in Morten Debian before upstream freezes their API. I think so too. I have python-pysnmp4 ready, available on the svn repository of debian-python team. I can package pysnmp3 too, but i would like to wait for Jan Luebbe answer about these mails ;). All versions use the pysnmp package name (and therfore the packages conflict against each other), so it would impossible to one package with depends on v2 together with one which depends on v4. 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. 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. -- Jan Lübbe [EMAIL PROTECTED]http://sicherheitsschwankung.de gpg-key 1024D/D8480F2E 2002-03-20 fingerprint 1B25 F91F 9E7B 5D4F 1282 02D6 8A83 8BE4 D848 0F2E signature.asc Description: This is a digitally signed message part
Bug#263417: ITP: pysnmp -- Python implementation of SNMP v.1/v.2c engine
Morten == Morten Werner Olsen [EMAIL PROTECTED] writes: Morten Doesn't the pysnmp 3.x-series have a very unstable API? And Morten is the 3.x-series still under development? I guess the right Morten thing to do is to make sure pykota uses the stable pysnmp Morten 2.x-series until a new stable 4.x-series is ready? Hello, 3.x-serie and 4.x-serie are unstable releases. Pykota doesn't use the 2.x-serie, only the 3.x-serie. But i think there are many examples of such python applications that use pysnmp2 or pysnmp3 or also pysnmp4, so i thnk that packaging all these branches could be great. Morten I'm not involved in the packaging of pysnmp, but I guess Morten packaging the 3.x- 4.x-series as separate packages sounds Morten like a good idea if we really want the version 3 and 4 in Morten Debian before upstream freezes their API. I think so too. I have python-pysnmp4 ready, available on the svn repository of debian-python team. I can package pysnmp3 too, but i would like to wait for Jan Luebbe answer about these mails ;). Regards, Arnaud Fontaine pgpbXjsqepM7g.pgp Description: PGP signature
Bug#263417: ITP: pysnmp -- Python implementation of SNMP v.1/v.2c engine
retitle 263417 ITP: pysnmp -- Python implementation of SNMP v.1/v.2c engine owner 263417 ! thanks Hello, I am interested by packaging this python module. I have already a sponsor. I will prepare a package this week. Regards, Arnaud Fontaine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
