On Mon, Nov 05, 2012 at 05:50:24PM -0500, Mike Gilbert wrote:
> On Mon, Nov 5, 2012 at 5:25 PM, Brian Harring <ferri...@gmail.com> wrote:
> > On Mon, Nov 05, 2012 at 01:15:45PM +0100, Micha?? G??rny wrote:
> >> And in case anyone wondered, the output looks like this:
> >>
> >> * PYTHON_TARGETS <-> USE_PYTHON inconsistency found. This may result
> >> * in missing modules when trying to use Python packages. Please ensure
> >> * that the same implementations are listed in both variables.
> >> *
> >> * Implementation python2_5 disabled but 2.5 in USE_PYTHON
> >> * Implementation python3_1 disabled but 3.1 in USE_PYTHON
> >> * Implementation jython2_5 enabled but 2.5-jython not in USE_PYTHON
> >
> > If you're going to complain to users about flags being disabled in
> > USE_PYTHON, use the actual flag name.
> >
>
> Those are the correct flag names.
Use flags can't have '.' in them, so no, that's not the correct flag
name; if you're going to tell folk "blah is not in USE_PYTHON", be
*accurate*- meaning dropp the /_/./ substitution.
> > Also... hopefully you typo'd, but 2.5-jython? Where was it decided
> > the naming there was being shifted around? None of the code in the
> > eclasses backs that text up from what I can tell.
> >
>
> That's no typo.
>
> 2.5-jython is the PYTHON_ABI from python.eclass. It means "version 2.5
> of the python language as implemented by jython". The intent is to
> allow for it to be matched by a glob pattern like "2.*" in
> RESTRICT_PYTHON_ABIS.
I'd forgotten that python eclass has PYTHON_ABI it ordered w/ the
python version first.
> > As floppym said; this flag isn't documented, so you're making it
> > fairly hard to actually comment/review on what you're doing here- we
> > just see glimpses of random patches, without knowing exactly what you
> > intend overall.
> >
>
> I think the scope of people who can review this is limited to those
> that have some understanding of how python.eclass functions; a limited
> subset indeed. ;-)
Y'all want reviews, then you need to help your reviewers. Really is
that simple.
Plus, bluntly, nobody wants another scenario of python.eclass w/ no
one understanding it.
Meaning what y'all are trying to develop/push, has to be
documented/understood by everyone. Strongly suspect this is why there
isn't any real review occurring for these patches coming in- no one
particularly knows wtf y'all are going with this.
> USE_PYTHON is a variable in python.eclass that python devs use to
> install python packages for any arbitrary python implementation,
> without using eselect python. sys-apps/portage knows nothing about it,
> and your typical user doesn't do anything with it.
Eh, two things;
1) info_vars; portage actually does report on it for emerge --info.
If it's internal (no users should be setting it), then you should
revert your addition of it to info_vars.
2) nothing in the tree actually uses it. Literally, niadda- just a
dead code section in python.eclass hinged on the var being exported.
Raising the question of why y'all are adding error reporting for this,
and what this is supposed to sort.
Not particularly digging the fact this warning y'all want to add is
ran everytime python_foreach_impl is fired also; meaning this will
spam logs if it ever hits.
> > Documenting your end goal (moving people to USE_PYTHON? etc) is kind
> > of necessary; normal rules of review reply, you want reviews, you make
> > sure your reviewers know wtf you're trying to do and ultimately why.
> >
>
> The end goal here is to migrate ebuilds to PYTHON_TARGETS. We can't
> migrate every package in the tree at once, so this check is being
> proposed to ensure that the user's settings for python.eclass
> (USE_PYTHON or eselect python --python{2,3}) and python-r1.eclass
> (PYTHON_TARGETS use-expand) match up.
>
> If they are out-of-sync, users may get build errors about missing
> modules. For instance, if dev-python/setuptools is installed with
> PYTHON_TARGETS="python2_7", but the user has python3.2 selected via
> eselect, they may get an error when they try to install packages using
> python.eclass if they depend on dev-python/setuptools.
>
> As we migrate more python libraries to python-r1, we can utilize
> use-deps to move this into the dependency resolver. This is something
> that was not possible with the old python.eclass.
This isn't quite what I'm asking for. I want y'all to literally
document thus:
1) What your finished solution is going to look like. Users control
which implementations are enabled via PYTHON_TARGETS, how y'all will
handle if no targets are currently specified (user hasn't made a
choice), etc.
2) How you're planning on getting there- literally, how things are
going to transition to your proposed replacement for python.eclass,
how the use deps will be structured, the potential gaps dependencye
wise as you go forward, etc.
As I indicated in my email, all folks see are changes coming in, no
sign of the actual end form you're intending, nor how you plan on
getting there.
I realize y'all may get pissed at being asked to layout your actual
plans... fact is, python.eclass got into this mess since people
couldn't track where it was going ultimately leading to the source
being spaghetti.
Lay out where y'all are going w/ this, and *how*, so people can
actually comment/contribute/avoid recreating another python.eclass
where no one understands it. :)
~harring
