$ qlist libpeas | grep python /usr/lib64/libpeas-1.0/loaders/libpython3loader.so /usr/lib64/libpeas-1.0/loaders/libpythonloader.so So it has two loaders that link to exactly *one* version of CPython 2 & 3. If you enable 3.3+3.4, you just get 3.4 and 3.3 is discarded. Worse than that, revdeps think 3.3 support is there and everything gets broken. Proper solution: REQUIRED_USE="?? ( $(python_gen_useflags 'python3*') )" i.e. allow enabling only one of Python3* targets (the only 2 target is 2.7 so we don't need REQUIRED_USE for that). And since there is no point in faking multi-impl support, the copy-build magic can be replaced by passing proper --enable-python2 --enable-python3. I think the simplest way of obtaining proper PYTHON*_CONFIG is to set them in the python_foreach_impl loop.
Fixed via REQUIRED_USE in gx86 & gnome overlay. I will also clean the gnome overlay ebuild up.
Since this means that dependencies (e.g. gitg) can support one version of Python3 as well, it would be nice if we could fix this issue instead of working around it. We already are copying the sources for the different python implementations. Can't we simply "sed" each source tree, replacing "python3loader" with "${EPYTHON}loader"? Or "${EPYTHON//./}loader" if dots in library file names could cause any kind of trouble.
And why should we make Gentoo libpeas incompatible with every other distribution in the world in yet another manner, and forcing ourselves to patch reverse dependencies randomly? And it's just not changing the loader -- it's actually changing the whole code to guess Python version, choose a loader and load the plugin in proper Python version. Does *anyone* really care about using gedit plugins with half a dozen Python versions in parallel?
(In reply to Michał Górny from comment #3) > And why should we make Gentoo libpeas incompatible with every other > distribution in the world in yet another manner, and forcing ourselves to > patch reverse dependencies randomly? And it's just not changing the loader > -- it's actually changing the whole code to guess Python version, choose a > loader and load the plugin in proper Python version. I hadn't seen any code changes along these lines in https://github.com/GNOME/libpeas/commit/590b5e1c3f11b4c5d6b15826aec05caeafaf9258 so I assumed that this would only be a build-time issue. But I guess I had the wrong direction for library use in mind: I was thinking about Python projects calling non-Python code. In that case it's important to support as many versions of Python as we can. But here the situation is reversed: this is about non-Python code calling Python extensions, right? So there is no (resonable) way to determine the Python version to use unless we introduce a bunch of new (and non-portable) names. I agree, that would be bad. > Does *anyone* really care about using gedit plugins with half a dozen Python > versions in parallel? Probably not. If you consider gedit, gitg and friends as applications, and libpeas as a specific library targeted at these applications, then being able to write code in ANY Python3 version should be sufficient. On the other hand, if that is your approach, then perhaps you should make gedit, gitg and so on use PYTHON_SINGLE_TARGET instead of PYTHON_TARGETS. After all, they can only use Python 3, and as they depend on libpeas and libpeas will not support more than one version of Python3, they can only use one version of Python as well. You might as well make that explicit. In fact, when I got the first message about libpeas having unsatisfied USE_REQUIRED requirements, I simply removed the Python 3.3 flag for that. But in the second step I got an error about gitg now having unsatisfied dependencies on libpeas, and this is what got me to write my comment #2. People shouldn't have to manually mask a bunch of Python 3 version USE flags for a bunch of reverse dependencies of one library, at least not if it can be avoided.
(In reply to Martin von Gagern from comment #4) > (In reply to Michał Górny from comment #3) > > Does *anyone* really care about using gedit plugins with half a dozen Python > > versions in parallel? > > Probably not. If you consider gedit, gitg and friends as applications, and > libpeas as a specific library targeted at these applications, then being > able to write code in ANY Python3 version should be sufficient. > > On the other hand, if that is your approach, then perhaps you should make > gedit, gitg and so on use PYTHON_SINGLE_TARGET instead of PYTHON_TARGETS. > After all, they can only use Python 3, and as they depend on libpeas and > libpeas will not support more than one version of Python3, they can only use > one version of Python as well. You might as well make that explicit. > > In fact, when I got the first message about libpeas having unsatisfied > USE_REQUIRED requirements, I simply removed the Python 3.3 flag for that. > But in the second step I got an error about gitg now having unsatisfied > dependencies on libpeas, and this is what got me to write my comment #2. > People shouldn't have to manually mask a bunch of Python 3 version USE flags > for a bunch of reverse dependencies of one library, at least not if it can > be avoided. Sadly, PYTHON_SINGLE_TARGET is causing more issues than it is solving right now, so I've temporarily restrained from using it with python3-only packages. We need to rethink the design and the issues it is causing, and probably find a better way. What's important is that the default profile settings don't require any extra actions -- those are enforced only if you enable multiple implementations. We are working on a good solution to that case. Or rather, trying to find one.
(In reply to Michał Górny from comment #5) [...] > Sadly, PYTHON_SINGLE_TARGET is causing more issues than it is solving right > now, so I've temporarily restrained from using it with python3-only > packages. We need to rethink the design and the issues it is causing, and > probably find a better way. What should we do with packages already using python-single-r1.eclass for python3 only packages? Move to python-r1.eclass? Is python-single-r1.eclass only meant for python2? Thanks for the info :)
(In reply to Pacho Ramos from comment #6) > (In reply to Michał Górny from comment #5) > [...] > > Sadly, PYTHON_SINGLE_TARGET is causing more issues than it is solving right > > now, so I've temporarily restrained from using it with python3-only > > packages. We need to rethink the design and the issues it is causing, and > > probably find a better way. > > What should we do with packages already using python-single-r1.eclass for > python3 only packages? Move to python-r1.eclass? Is python-single-r1.eclass > only meant for python2? Keep using python-single-r1 whenever possible. Any chances to come will happen within the eclass since it's simply more convenient than python-r1. However, I've switched libpeas reverse deps to python-r1 with REQUIRED_USE=^^ ( ... ) temporarily since that's where the issue is manifesting itself.
