Apologies for the cross-posting, but I think both lists will have valuable input on this issue. As part of Ubuntu's push to ship only Python 3 on our desktop image, I'm now looking at libpeas (Gnome plugin system). The good news is that upstream supports Python 3.2 and 2.6/7 just fine, however the Debian packaging only builds for the default the Python 2 version. I've had a few discussions with some other developers, but none of us have actually used libpeas so I'm looking for more feedback. Debian's packaging gives us /usr/lib/libpeas-1.0/loaders/libpythonloader.so in its libpeas-1.0-0 binary package. What's the best way to provide a Python 3 version of the loader? Our first thought is to split the packaging into a python-libpeas package and a python3-libpeas package. The former would provide /usr/lib/libpeas-1.0/loaders/libpythonloader.so and the latter would provide /usr/lib/libpeas-1.0/loaders/libpython3loader.so. (Of course, we'll have parallel twiddling for the debug packages.) Then, IIUC, clients which want to use the Python 3 loader would specify "python3" to peas_engine_enable_loader() and specify 'python3' as Loader in their .plugin section. I don't want to add Conflicts headers to the python-libpeas and python3-libpeas packages because I think it's entirely reasonable to have mixed Python 2 and Python 3 libpeas plugins on the same *system*, but of course it makes no sense to have mixed plugins in the same *application*. Would a Build-Conflict in the binary packages help to prevent this, or do we need something more somewhere (i.e. in the libpeas Python layer, or do we just let the consenting adults rule keep us safe?). What do you think? I'm willing to work up a patch, once consensus has been reached on the right way to provide Python 3 support. Cheers, -Barry
Attachment:
signature.asc
Description: PGP signature