Re: pysnmp ?

From: Tomoaki AOKI <junchoon_at_dec.sakura.ne.jp>
Date: Sat, 30 Mar 2024 19:18:52 UTC
On Sun, 31 Mar 2024 02:59:39 +0900
Hiroo Ono <hiroo@oikumene.net> wrote:

> On Sat, 30 Mar 2024 21:30:26 +0900
> "SEGAWA Tomo." <rnm2wgs@nagoya-u.jp> wrote:
> 
> >  瀬川@瀬戸と申します。
> > 
> >   FreeBSD 13.* で pkg の py39-pysnmp-4.4.9_2 を使えなくなって
> > しまって、助けて頂けませんか?
> > 
> >   python で "from pysnmp.hlapi import ..." しているプログラム
> > が 2023年10月頃に py39-pyasn1 が更新
> >     py39-pyasn1 upgraded: 0.4.8 -> 0.5.0
> > されてから、動かなくなってしまいました。error の症状は
> >     https://github.com/etingof/pysnmp/issues/440
> > で報告されているのとほぼ同じです。
> 
> そこで言及されている pyasn1 の issue に pyasn1 0.5.0 との組み合わせで動かす patch があります。
> ただ、今度は pyasn1 の 0.48 と incompatible になるので、pysnmp ですぐに取り入れられるかは
> よくわかりません。
> https://github.com/pyasn1/pyasn1/issues/28#issuecomment-1517029636
> 
> 解決手段としては、
> 1) とにかく早くなんとかしたい場合は、上記をローカルパッチとして ports から pysnmp をビルドする。
> 2) ports 的に正規の手順をとるならば、
>   - 上記 issue を参照しつつ、ports の patch として bugzilla で報告して
>   - 必要な理由を説明。(ports の pyasn1 は 0.5.0 になってしまっているので、pysnmp もそれに
>     対応する必要があるというところでしょうか)
>   - メンテナをせっついて approval をもらう。
>   - approve してもらったら、freebsd-ports@ で誰かコミットしてとお願いする。
>   とやればまあまあ早く commit してもらえると思います。

青木@名古屋です。

2) ですが、devel/pyasn1の方でとっとと0.5.1以降に更新して貰う方向も
ありそうですね。 対応して貰う手順的には同じですが、ざっと検索して
みたら[1]がヒットしました。
昨年4月に報告されたもののようですが、既知の問題で片付けられて
Openのままになっているようです。

結局、

 ・pyasn1を0.4系にダウングレードする
 ・pysnmpを積極的にメンテナンスされているforkのpysnmp-lextudio
  なり何なりに乗り換える

というワークアラウンドが提示された後、pyasn1の0.5.1で互換性問題が
修正されているから更新しろ、という話に変わっているようです。
ついでに、昨年11月になって、pssnmpも新しいバージョンでpyasn1 0.5.1を
デフォルトにしているのでこの問題は再発しないだろうとも言っていますね。
その割に、タグが打たれているのは4.4.12までで5年前、4.4.13のブランチは
4年前のようですがタグが打たれていないしmasterより新しいようなので
リリース準備中臭いのが少々怪しい気もします。

pyasn1の本家[2]では0.5.1の後に0.6.0のタグが打たれています。
リンク先は0.5.1のタグで表示した状態です。
どのように修正されたかまでは、宗教上(笑)の理由でPythonのコードは
エラーメッセージ以外読まないため確認していませんので、0.5.0に
対応したコードでエラーが出る恐れはありますが、メンテナがBugzillaに
テスト用のパッチを上げてくれれば(自分でパッチ当て・ビルドは必要に
なりますが)他のdevel/py-pyasn1依存物が対応できる体制が整ってコミット
される前に問題解決できるかもしれません。
一応、[3]で0.4系と0.5系の両APIに透過的に対応と称していますが。

※単に、2系から3系に上げる時点で2系のコードを扱えなくしたPythonを
 言語処理系として認めたくないだけです。 Cコンパイラなど、LLVM
 /Clang17でさえオプションを付ければ原初のK&Rのコードを処理して
 くれますし、これが言語処理系のあるべき姿です。 互換性のない
 言語仕様の変更にはそのメンテナンスコストも覚悟すべきでしょう。
 嫌なら自分たちが旧版を使いたい人たちに引き継いで、自分たちは
 原著作者であることを背景にForkしてそっくりでありつつ一部非互換な
 新言語として立ち上げればいいのです。


[1] https://github.com/etingof/pysnmp/issues/438

[2] https://github.com/pyasn1/pyasn1/tree/v0.5.1

[3] https://github.com/pyasn1/pyasn1/blob/v0.5.1/CHANGES.rst


-- 
青木 知明  [Tomoaki AOKI]    <junchoon@dec.sakura.ne.jp>