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

[Mike Gilbert]

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.

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

> *) removes the ability to do $PYTHON_INTERP /usr/bin/script
>

Nobody dreamed up this scenario when python-exec was proposed. It
seems pretty obvious now, but I didn't think about it until our email
exchange about your original proposal.

> These are the sort of things that would've been identified with tests.
>

I don't see how tests themselves would have identified these issues,
since we are talking about testing use cases that had not yet been
identified. Or that had deliberately been changed, in the case of the
script rename.

I guess you may be implying that thinking of test cases would have
triggered some deeper thought and revealed flaws that were not
immediately apparent. That's probably true.


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


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.


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.


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.