"OBATA Akio" <obache%netbsd.org@localhost> writes: > On Mon, 08 Jul 2013 22:25:32 +0900, Ryo ONODERA > <ryo_on%yk.rim.or.jp@localhost> wrote: > >> Sorry again. >> gedit3 with PYTHON_VERSIONS_ACCEPTED=32 33 picks up py32-gobject3, >> but libpeas only picks up python27, not python32. >> py32-gobject3 is not installed. >> >> I feel it is expected behavior, but something should be improved >> in latest gedit3 (and libpeas) case. > > Hmm, it is impossible to add multiple python variant support to > pythonloader provided by libpeas. > I feel that it is the origin of this issue. It's certainly possibly to have pyNN-libeas and have N copies installed (entirely) under paths with pythonN.N in the name, with each having one hardcoded version. And then fix all users to look for it that way. But I'm not suggesting that it's a good idea. So I think we've arrived at (and have been there a long time): some python programs have pyNN support some don't programs that don't use the system version. Everything that depends on programs that don't have to use the system version. Programs and libraries that don't work with the system version are just unusable. python 3 is going to be painful because of this, because people are depending on python 3 before it's reasonable to tell people that if their python code doesn't work with 3, they are lame and in such a minority that it's ok to discard their code. Does anyone know how is this being handled in the Linux world? As I understand it, they are less into pyNN than we are. For py2N, one can sort of get away with that. But 2/3 seems not really workable as a single choice.
Attachment:
pgpYJ2wHZa7uH.pgp
Description: PGP signature