Re: [gentoo-python] Re: The future of PYTHON_SINGLE_TARGET

[Michał Górny]

Dnia 2014-11-30, o godz. 13:12:18
Mike Gilbert <floppym@g.o> napisał(a):

> On Fri, Nov 28, 2014 at 5:59 PM, Michał Górny <mgorny@g.o> wrote:
> > As far as the first issue is concerned, I think enough has been said
> > already. Right now we are fine-tuned for two cases:
> >
> > a. packages that support one impl only -- then they have a single
> > PYTHON_TARGET that's enabled by default,
> >
> > b. packages that support python2.7 -- then we have the profile default
> > of python2.7 for them.
> >
> > We have no good way of handling packages that support Python 3 only.
> >
>
> I'm thinking we need to move the default PYTHON_SINGLE_TARGET setting
> from profiles to IUSE defaults computed in the eclass.
>
> What are the problems associated with that?

Well, one issue I see is that it means we will have a 'moving' default.
That is, different packages will have different (non-matching) defaults
depending on supported implementations. Worse than that, adding a new
implementation will change the default in one package which may conflict
with its dependencies.

Please consider the following example. We have two packages, AA and AB.
Both are python-single-r1 and in version 1 both support 3.2+3.3, with
3.3 being the IUSE default. AB depends on AA[${PYTHON_USEDEP}].

Now, A-2 gets 3.4 support and 3.4 becomes the IUSE default. Now emerge
-1vDtuN ab gives:

emerge: there are no ebuilds built with USE flags to satisfy
"dev-python/aa[python_targets_python3_3(-),python_single_target_python3_3(+)]". !!!
One of the following packages is required to complete your request:
- dev-python/aa-2::mgorny (Change USE: +python_single_target_python3_3,
this change violates use flag constraints defined by dev-python/aa-2:
'exactly-one-of ( python_single_target_python3_2
python_single_target_python3_3 python_single_target_python3_4 )
python_single_target_python3_2? ( python_targets_python3_2 )
python_single_target_python3_3? ( python_targets_python3_3 )
python_single_target_python3_4? ( python_targets_python3_4 )')
(dependency required by "dev-python/ab-1::mgorny" [installed])
(dependency required by "ab" [argument])

This happens both when PST USE-deps are '?' and '='.

Now, assuming that user actually adds 3.3, he gets regular REQUIRED_USE
conflict. He can solve it by removing 3.4 *explicitly*. Now he can
upgrade. Note that PYTHON_TARGETS has 3.3+3.4 now (see issue below).

Now good news, everyone! AB just gained 3.4 support, and therefore
switched default again. Now portage at least suggests the right thing
to do:

The following USE changes are necessary to proceed:
 (see "package.use" in the portage(5) man page for more details)
# required by dev-python/ab-2::mgorny
# required by ab (argument)
>=dev-python/aa-2 python_single_target_python3_4 -python_single_target_python3_3

This is good so far. Now, let's imagine we have three packages -- AA,
AB and AC. AC also depends on AA and supports 3.2+3.3. This means that
once AB and AA again 3.4 support, Portage ends up having a real
conflict:

!!! Multiple package instances within a single package slot have been
pulled !!! into the dependency graph, resulting in a slot conflict:

dev-python/aa:0

  (dev-python/aa-2:0/0::mgorny, installed) pulled in by
    dev-python/aa[python_targets_python3_3(-),-python_single_target_python3_2(+),python_single_target_python3_3(+)]
  required by (dev-python/ac-1:0/0::mgorny, installed) 

  (dev-python/aa-2:0/0::mgorny, ebuild scheduled for merge) pulled in by
    dev-python/aa[python_targets_python3_2(-)?,python_targets_python3_3(-)?,python_targets_python3_4(-)?,python_single_target_python3_2(+)=,python_single_target_python3_3(+)=,python_single_target_python3_4(+)=]
  required by (dev-python/ab-2:0/0::mgorny, ebuild scheduled for merge)


Not good at all. Portage still suggests enabling 3.4 on AA but that
only makes things worse. If you force 3.3 on AB, it lets you continue.

Once AC gets 3.4, Portage says to switch AA to 3.4. Once you do that,
it tells you to switch it to 3.3 (because of AB). Guess what it tells
you to do next :).

> > The other issue comes into game in two cases I've seen:
> >
> > A. when we try to improve setting of PYTHON_SINGLE_TARGET, we force
> > the user to enable matching PYTHON_TARGET anyway -- so in the end
> > manual intervention is required,
>
> That would seem to be the exception rather than the norm. This would
> only happen if we somehow defaulted PYTHON_SINGLE_TARGET to something
> that is not in PYTHON_TARGETS by default. How would that ever happen?

Forget about this. I guess we can enable the same PYTHON_TARGET
and PYTHON_SINGLE_TARGET via IUSE defaults.

> > B. they cause issues with REQUIRED_USE on other packages (like libpeas
> > that supports only one version of python2 and one of python3). Even
> > though PYTHON_SINGLE_TARGET results in effective use of a single impl,
> > PYTHON_TARGET USE-dep requests full PYTHON_TARGETS match on the dep.
> > Therefore, the user needs to disable other implementations anyway to
> > get the expected result.
>
> I don't understand this part. Can you please explain it? Maybe an example?

gedit and libpeas, with gedit depending on libpeas. libpeas supports
one version of Python 2 and one of Python 3, and gedit just one
in general:

libpeas is REQUIRED_USE=?? ( 2.* ) ?? ( 3.* )
gedit is REQUIRED_USE=^^ ( 3.* )

So libpeas needs python-r1 with specific REQUIRED_USE. gedit would be
a candidate for python-single-r1 but...

p-s-r1 enforces ^^ only on PYTHON_SINGLE_TARGET. So I end up with
something like:

  PYTHON_TARGETS="3.3 3.4" PYTHON_SINGLE_TARGET="3.4"

and this enforces dependency on libpeas[3.3,3.4] which contradicts its
REQUIRED_USE. So we need also REQUIRED_USE=^^ ( 3.* ). But basically,
the whole mess with the second variable doesn't really help here.

-- 
Best regards,
Michał Górny