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

[Brian Harring]

On Sun, Nov 11, 2012 at 01:35:20PM -0500, Mike Gilbert wrote:
> 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.

Just a note; portage's behaviour here, per the norm, is more stupid 
than that.  EAPIs 0-4 are supposed to /not/ have that filtering, 
meaning portage broke it's own behaviour again.

I suspect we'll retroactively change EAPIs to compensate for this, but 
I don't know for a fact; the discussion for that will occur at 
https://bugs.gentoo.org/442830 .


> 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.

As stated, I'll do the work if it decreases the pains for users and 
eases transition (whether it be USE_PYTHON or PYTHON_TARGETS).


> 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.

This is why I asked for the "basic legwork" that involves a 
roadmap/plan beyond the immediate patch.

The news item has had 5 days of exposure to users.  It's a bit 
amateur-hour to have to pull it, but if the USE_PYTHON fix-it route is 
ultimately less transition pain for users, we should go down that 
path.

I *suspect* that route may not be best, although if PYTHON_TARGETS is 
choosen as the approach, that news item (or another) needs to be cut 
explicitly clarifying that everything is moving away from USE_PYTHON.

Folks may view it as "an internal", but users have been using it.


> 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.

Either USE_PYTHON or PYTHON_TARGETS; the proposed notion of both is a 
recipe for pain.  To be clear, any proposal that involves both 
existing long term is an automatic -1 from me.

~harring