tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: python32 and python33 dependencies from a package

"OBATA Akio" <> writes:

> On Mon, 08 Jul 2013 22:25:32 +0900, Ryo ONODERA 
> <> 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

Home | Main Index | Thread Index | Old Index