[gentoo-python] Package supporting single implementation only -- auxiliary variable solution

[Michał Górny]

Hello,

I am still thinking what would be the best way of handling packages
which support being built for a single Python implementation only
(like packages embedding Python and not being boost).

A few shortcuts for the scope of this mail:
SIP - package supporting being built for a single implementation only
MIP - package supporting being built for multiple implementations

Now, the problem with SIP is that they can support only one Python
implementation at a time. I'd like to find a solution which:

1) would be the most user- and developer-friendly,

2) would be transparent and explicit (user has to know which
implementation is actually used, and be able to switch it),

3) would not require different dependency atoms for dependencies which
are SIP (i.e. the package just depends on another Python package,
not caring whether it is SIP or MIP).


So far, the solution of using REQUIRED_USE='^^ ( python_targets... )'
fulfilled 2) & 3). Sadly, it is hardly user-friendly because whenever
user has more than one Python implementation in PYTHON_TARGETS, he
needs to explicitly disable other flags for each package.

Additionally, this means that if SIP becomes a MIP, user is unaware
of that and still explicitly disables additional implementations.

I could live with that if not the fact that the default PYTHON_TARGETS
currently list two implementations. Therefore, not only a specific
group but all our users would be forced to switch flags like that.


Hopefully, there's one way we could achieve a bit of user-friendliness
for most of the cases. If we introduced an auxiliary variable, let's
call it PYTHON_SINGLE_TARGET for now, it could work.

The eclass used for SIP:

1) adds PYTHON_SINGLE_TARGET flags (following PYTHON_COMPAT) to IUSE,

2) adds REQUIRED_USE='^^ ( python_single_target... )',

3) adds REQUIRED_USE='python_single_target...? ( python_targets... )',

4) replaces PYTHON_USEDEP with:
       'python_targets...?,python_single_target...?(+)',

5) sets the variables based on PYTHON_SINGLE_TARGET in pkg_setup().

Therefore, users can explicitly use PYTHON_SINGLE_TARGET to choose
the target which would be user for SIP while keeping the complete
PYTHON_TARGETS for MIP. It's much more friendly.


Thanks to EAPI4 USE defaults, the ${PYTHON_USEDEP} works fine both
for MIP and SIP deps.

For a MIP dep, the PYTHON_TARGETS are used as the real check.
PYTHON_SINGLE_TARGET aren't there and they default to enabled,
so the check passes. The REQUIRED_USE ensures that PYTHON_TARGETS
contains PYTHON_SINGLE_TARGET.

For a SIP dep, the PYTHON_SINGLE_TARGET is available and becomes
relevant.

In the corner case when PYTHON_SINGLE_TARGET for package A specifies
an implementation which is not supported by package B,
the PYTHON_SINGLE_TARGET check succeeds (missing flag = enabled)
but the PYTHON_TARGETS check fails due to missing flag.

Of course, a MIP would not be allowed to depend on a SIP.


The profiles would specify a single default implementation
from PYTHON_TARGETS as a default for PYTHON_SINGLE_TARGET. This will
effectively hide the issue from most of our users.

Those who set PYTHON_TARGETS explicitly may need to adjust
the PYTHON_SINGLE_TARGET. Considering that it will be common to all
SIPs, it's much more friendly than switching per-package.


The only real issue unsolved is friendly solving of Py2/3 issues with
SIPs. If user has PYTHON_SINGLE_TARGET=python2_7, SIP package supporting
Python3 only (is there any?) would require explicit flag setting.

I believe that's a corner case. It could be solved if we invented some
kind of 'automatic USE defaults'. In that case, profiles wouldn't
specify a default but instead portage would pick one based on
REQUIRED_USE constraints and flag order.

In other words:
- user has PYTHON_TARGETS='python2_7 python3_2',
- package has PYTHON_COMPAT=( python{2_6,2_7} ),
-> per-package PYTHON_TARGETS becomes 'python2_7',
- REQUIRED_USE='^^ ( pst2_6 pst2_7 ) pst2_6? ( py2_6 ) ...'
-> portage tries pst2_6...
--> py2_6 not set, REQUIRED_USE unsatisfied;
-> portage tries pst2_7
--> py2_7 set, all ok.
---> PYTHON_SINGLE_TARGET=python2_7

But that's not really necessary right now, I think.


To sum it up quickly, the aux variable solution:

Advantages:
- painless for most of our users,
- explicit, transparent,
- simple and matching SIP->SIP and SIP->MIP deps.

Disadvantages:
- a bit redundant,
- does not solve the issue for py3-only SIP packages,
- may require explicit action when changing PYTHON_TARGETS.

What are your thoughts?

-- 
Best regards,
Michał Górny