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

[Brian Harring]

On Sat, Nov 10, 2012 at 05:43:22PM +0100, Micha?? G??rny wrote:
> Hello,
>
> As some of you are aware already, there is a significant difference
> in handling Python implementation choice between python.eclass
> and python-r1 / p-d-ng.
>
> The python.eclass packages use USE_PYTHON (undocumented variable)
> or the eselected Python2+3, and store that choice implicitly.
> Everything works on the assumption that implementations don't change
> or user runs python-updater.
>
> The python-r1 / p-d-ng packages use explicit USE flags to choose
> implementation. The choice is thus explicitly exported and other
> packages can use USE dependencies to enforce matching implementations.
>
> The problems arise whenever python-r1 package depends on package using
> the python.eclass, or the other way round. There is no clear way to
> enforce the same implementations being used, so everything falls down
> to user.
>
> In order to solve the most common problems due to that, I have
> published a news item explaining how PYTHON_TARGETS work and what needs
> to be done with them.
>
> In the discussion with other Gentoo Python devs, it was assumed that
> USE_PYTHON should not be considered public and thus not be described
> in the message. Sadly, it seems that this resulted in people actually
> trying to disable Python3 using PYTHON_TARGETS and seeing random
> failures due to python.eclass enforcing it anyway.
>
>
> I believe we should thoroughly think what should be done now in order
> to solve the issues best for the transition time. Here are a few
> solutions I can think of.

Honestly... if we care this much about USE_PYTHON, then we should use 
it, rather than PYTHON_TARGETS.

Mind you, I'm aware someone ignored repeatedly being told "do not 
fucking use periods in the targets- it cannot be allowed as a use flag 
due to compatibility issues in profiles"- meaning we have to dig 
out of a mess that was foresaw, but such is life.

Fixing USE_PYTHON is simpler than trying to get users to migrate to a 
new var, let alone keep those two vars in sync.

To get there, we'd have to basically accept 2.6/2_6 in USE_PYTHON w/in 
python.eclass (a modification I will sort if others won't), have it 
spit warnings, then flip it to a USE_EXPAND target.

Portage, fortunately, is lose in this department- you can have a 
USE_EXPAND target w/ invalid use chars in it.  It's just not usable in 
use dependencies nor IUSE, making it a dead setting if it uses invalid 
chars.

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.


> 1) lard both eclasses with USE_PYTHON <-> PYTHON_TARGETS consistency
> checks. This should be pretty easy for python-r1, harder for
> python.eclass (anyone volunteering to touch it in thick gloves?).
>
> In other words, we just warn users whenever they need to do something
> to ensure things work.
>
>
> 2) make python.eclass respect PYTHON_TARGETS.
>
> Sadly, due to PMS limitations we can't tell if PYTHON_TARGETS was set
> by user or has the default value. So we either can:
>
> a) stop using USE_PYTHON and eselect defaults, start using
> PYTHON_TARGETS only, pull in correct Python versions, tell users to run
> python-updater;

Just a note; we /never/ should listen to eselect defaults, only USE 
enforced configuration; I'm appreciative you've not replicated that 
python.eclass idiocy since it craps all over 
deterministic/reproducible builds.

~harring