Re: [gentoo-python] Re: [PATCH eselect-python 1/2] Store per-version interpreter preference in a file as well.

[Brian Harring]

On Sat, Nov 03, 2012 at 11:55:37AM -0400, Mike Gilbert wrote:
> On Sat, Nov 3, 2012 at 7:47 AM, Brian Harring <ferringb@×××××.com> wrote:
>
> Some quick notes on these last points. Don't get too hung up on this;
> my general opinion of the solution follows at the end.
>
> > Your implementation mandates the following:
> >
> > *) scripts be changed from sphinx-build-2.7 to sphinx-build-python2.7.
> >
>
> The was a design decision to simplify the implementation in
> conjunction with the new eclass and avoids having to map a plain
> number (2.7) to an actual interpreter name (python2.7). I still like
> this idea, but it really isn't safe to do this in the old eclass.

Renaming sphinx-build-2.7-pypy-1.8 to sphinx-build-pypy-c1.8 (or just 
1.8) personally I think is sane; the original naming was off, and I 
doubt any code actually hardcodes it.

I don't see the point in shoving -pythonx.y when -x.y 
suffices however- the parsing scenario there is easy to handle for 
any wrapper, and is understood for folks these days.

Additionally, because the advocated route of forcing a specific interp 
for a target has thus been invoking the interpretter specific script 
(sphinx-build-2.7 for example), changing the name for python means 
breakage may occur.

How much breakage, I've no clue; just pointing out that it is 
possible.


> > *) mandates symlinks of python-EPYTHON were it to be attempted to be
> > used for python-wrapper.
> >
>
> python-exec was not originally intended to replace python-wrapper so
> there is no code in place to handle this more gracefully.

It was proposed, which is why I responded to it.

Same angle, the cons of python-exec compared to python-shebang were 
asked, so this got brought up.  python-wrapper is literally just a a 
simple re-exec around python-shebang now.


> > Python herd, assuming you've not ignored the thread due to the noise,
> > your views would be useful.
>
> Just so everyone is on the same page here: python-exec was invented as
> an answer to the problem of how to implement script wrappers in the
> new eclass. The new eclass(es) were invented because nobody wanted to
> make significant modifications to the old one, given its complexity
> and code style.
>
> I don't think we were aiming for a perfect solution with python-r1 and
> python-exec, rather one that was simple so people could understand,
> and worked in the cases we considered at the time.
>
> Your main goal with python-shebang seems to be a fix to the "python2.7
> /usr/bin/sphinx-build" thing, which is fine. But it lead you to a
> different place.

Close; my main goal was replacing that fucking python wrapper, and 
fixing `python2.7 /usr/bin/sphinx-build` while speeding everything up.

I've got a couple of core requirements, but they pretty much sum up to 
"the existing wrapper needs to die"- everything else (de-duplication 
reducing the number of files on disk) is icing on the cake.


> That said, I like this python-shebang solution, and your replies to
> mgorny's questions have provided very useful insight.
>
> However, I have a few issues:
>
> 1. I still don't really understand the guts of python-shebang.
>
> It's a significant chunk of C that is doing things I am not yet
> familiar with. I'm sure I can figure it out if I take some time, but
> right now I have a "fear of the unknown" thing happening in my head.
>
> I don't want us to end up with only you understanding how to modify that code.

That can be rectified via more comments.  Honestly it's pretty simple- 
just trace the main(); everything else is just helpers to it.  The 
flow there should be pretty clear as to what it's doing.

The actual invocation scenarios, and details of how it covers each of 
those, can be addressed via a README (or similar) easily enough.  
There's a few subtlies there as to how it manages to do the correct 
thing, which I should document.


> 2. Somebody needs to write the python.eclass code if we really want to go there.
>
> I think we would need to modify
> python_merge_intermediate_installation_images, and replace
> python_generate_wrapper_scripts. If anyone wants to take a crack at
> it, great.

Already have local patches to that effect; as indicated in my original 
email, I'm busy with some other things atm, but I'll loop back to it 
in the next week or two.

If someone else wants to finish it, they're free to.  Else I will.


> 3. We need to reconcile the script naming convention so we can use
> this with the new eclass as well.
>
> I just don't see us implementing PYTHON_TARGETS in python.eclass. I
> have considered it, but I just don't have the motivation to do it. I
> still think we are going to proceed with the python-r1 effort.
>
> What do you think about extending python-shebang to understand the
> script-$EPYTHON naming convention in addition to the
> script-$PYTHON_ABI convention? I only ask because I dislike the
> $PYTHON_ABI values and would rather not see that re-implemented in
> python-r1. I think script-$EPYTHON gives a clearer indication as to
> its intended purpose anyway.

Off the top of the head, it's easy enough to support both w/ 
python-shebang code; it's just an extra case or two for the core 
parsing.

I *do* intend to keep the current parsing in place though- as I said, 
I want this idiocy fixed in python.eclass now (and as demonstrated, 
I'll do the work myself if necessary).  Removing that blob of code out 
of python.eclass won't fix the eclass, but it'll at least bring down 
the line count a bit so there's less to have to work with.

Plus if a replacement actual ground, this component doesn't need 
changing (if it ain't broke, don't fix it).

~harring