On Mon, Nov 5, 2012 at 6:34 PM, Brian Harring <ferri...@gmail.com> wrote:
> 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.
>
USE_PYTHON does not enumerate USE flags. It contains a list of PYHTON_ABIs.
>
>> > 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.
>
That's intended for use in bug reports, so members of the python team
can confirm the user's configuration. When I say it is to be used by
devs, I mean that developers and "power users" set it in make.conf,
not that it is set in ebuids.
> 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.
>
Every ebuild in the tree which inherits python.eclass and sets
SUPPORT_PYTHON_ABIS utilizes USE_PYTHON if it has been set in the
environment or in make.conf. I think you misinterpreted my meaning
here.
> 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. :)
>
I will admit right now that I don't have a "master plan" in mind, and
we are sort of making it up as we go along. I am not a software
engineer; I just like to read/hack on code. I would love for some
master architect to come along and document where we are headed, but
that hasn't happened. And I'm not the person to do it -- it just
doesn't interest me.
mgorny has been writing lots of code and is looking for someone to
review it. I'm very good at answering specific questions and offering
an informed opinion, so I'm attempting to do so.
