Re: [gentoo-python] python-r1 <-> python.eclass package dependencies

[Mike Gilbert]

On Sun, Nov 11, 2012 at 2:52 AM, Brian Harring <ferringb@×××××.com> wrote:
> So... thus:
>
> 1) make python.eclass know of both forms of USE_PYTHON (with periods,
> without).
> 2) convert USE_PYTHON to a use expanded target
> 3) convert python.eclass to use it.
>
> I realize this deprecates/kills PYTHON_TARGETS; my intention here
> isn't to piss on the var you added, it's to choose the less disruptive
> option here- lesser of two evils.  Starting from scratch,
> PYTHON_TARGETS would be fine- unfortunately we need to map existing
> users (and usage) from python.eclass into the replacement,
> constraining our choises a bit.
>
> Counter arguments?  To be clear, this is the path I strongly suggest
> we take- if you can punch holes in the logic/arguments from above, I'd
> definitely back down, but the use of PYTHON_TARGETS here feels like
> we're setting ourselves up for unnecessary pain.  Keep in mind not
> *all* of python.eclass notions/setup has to be chucked- we can
> translate certain parts of it across to ease developer/user pains.
>

Following up on this and the irc conversation I eavesdropped on earlier:

More recent versions of portage apparently filter USE_EXPAND
variables, so we can't utilize the old python abi values in USE_PYTHON
if we make that conversion.

Converting USE_PYTHON to a use-expand would entail the following in
python.eclass:

1. Convert between values like "2_7-pypy-1_9" and "2.7-pypy-1.9"
The underscore version would be used for USE and IUSE and in portage
config (make.conf, profiles?).
The dot version should be used by the eclass and ebuilds and in
on-disk file names for backward compatibility.

2. Calculate the python abis supported by the ebuild based on
_PYTHON_GLOBALLY_SUPPORTED_ABIS and RESTRICT_PYTHON_ABIS. Add these
abis to IUSE.
This would affect all ebuilds inheriting python.eclass with
SUPPORT_PYTHON_ABIS set.

This should not be difficult, but you never know with python.eclass.
Personally, I just assume that nobody actually wants to touch
python.eclass if it can be avoided.

Also, we have dug ourselves into a small hole with PYTHON_TARGETS;
there is actually a news item out there that explains its use
(committed about the same time Brian put on the breaks), so we are
going to cause confusion if it is changed back to USE_PYTHON. I
realize this is not a reason to charge blindly forward with
PYTHON_TARGETS, but it needs to be considered.

I think the only benefit to keeping the USE_PYTHON name is so that
existing users don't have to learn another variable name. They would
still need to tweak their config.