On Mon, Nov 5, 2012 at 5:25 PM, Brian Harring <ferri...@gmail.com> wrote:
> On Mon, Nov 05, 2012 at 01:15:45PM +0100, Micha?? G??rny wrote:
>> And in case anyone wondered, the output looks like this:
>>
>> * PYTHON_TARGETS <-> USE_PYTHON inconsistency found. This may result
>> * in missing modules when trying to use Python packages. Please ensure
>> * that the same implementations are listed in both variables.
>> *
>> * Implementation python2_5 disabled but 2.5 in USE_PYTHON
>> * Implementation python3_1 disabled but 3.1 in USE_PYTHON
>> * Implementation jython2_5 enabled but 2.5-jython not in USE_PYTHON
>
> If you're going to complain to users about flags being disabled in
> USE_PYTHON, use the actual flag name.
>
Those are the correct flag names.
> Also... hopefully you typo'd, but 2.5-jython? Where was it decided
> the naming there was being shifted around? None of the code in the
> eclasses backs that text up from what I can tell.
>
That's no typo.
2.5-jython is the PYTHON_ABI from python.eclass. It means "version 2.5
of the python language as implemented by jython". The intent is to
allow for it to be matched by a glob pattern like "2.*" in
RESTRICT_PYTHON_ABIS.
We have basically abandoned the PYTHON_ABI concept with the new
eclass. Instead, we have values in PYTHON_TARGETS, which match up to
an implementation and version. For example: jython2_5, for
dev-java/jython-2.5.
> As floppym said; this flag isn't documented, so you're making it
> fairly hard to actually comment/review on what you're doing here- we
> just see glimpses of random patches, without knowing exactly what you
> intend overall.
>
I think the scope of people who can review this is limited to those
that have some understanding of how python.eclass functions; a limited
subset indeed. ;-)
USE_PYTHON is a variable in python.eclass that python devs use to
install python packages for any arbitrary python implementation,
without using eselect python. sys-apps/portage knows nothing about it,
and your typical user doesn't do anything with it.
PYTHON_TARGETS is a similar variable that was introduced in python-r1
(python-distutils-ng actually). It is a use-expanded variable so that
portage can actually use its values for dependency resolution.
> Documenting your end goal (moving people to USE_PYTHON? etc) is kind
> of necessary; normal rules of review reply, you want reviews, you make
> sure your reviewers know wtf you're trying to do and ultimately why.
>
The end goal here is to migrate ebuilds to PYTHON_TARGETS. We can't
migrate every package in the tree at once, so this check is being
proposed to ensure that the user's settings for python.eclass
(USE_PYTHON or eselect python --python{2,3}) and python-r1.eclass
(PYTHON_TARGETS use-expand) match up.
If they are out-of-sync, users may get build errors about missing
modules. For instance, if dev-python/setuptools is installed with
PYTHON_TARGETS="python2_7", but the user has python3.2 selected via
eselect, they may get an error when they try to install packages using
python.eclass if they depend on dev-python/setuptools.
As we migrate more python libraries to python-r1, we can utilize
use-deps to move this into the dependency resolver. This is something
that was not possible with the old python.eclass.
