From: Brian Harring <ferringb@gmail.com>
To: Mike Gilbert <floppym@gentoo.org>
Cc: Micha?? G??rny <mgorny@gentoo.org>, gentoo-python@lists.gentoo.org
Subject: Re: [gentoo-python] Re: [PATCH eselect-python 1/2] Store per-version interpreter preference in a file as well.
Date: Sat, 3 Nov 2012 14:31:12 -0700 [thread overview]
Message-ID: <20121103213112.GB3150@localhost> (raw)
In-Reply-To: <CAJ0EP41bCK=naZHToqtwwceN=-mh5Bm1CZCJmD4yAWXDND0buQ@mail.gmail.com>
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@gmail.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
prev parent reply other threads:[~2012-11-03 21:31 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-01 11:54 [gentoo-python] [PATCH eselect-python 1/2] Store per-version interpreter preference in a file as well Michał Górny
2012-11-01 11:54 ` [gentoo-python] [PATCH eselect-python 2/2] Re-set the same interpreters on 'update --if-unset' Michał Górny
[not found] ` <CAJ0EP41Ww9GKYto8A8gX-L+D2=3+MFhYHmUZXZNvm+Ni5ApSbw@mail.gmail.com>
2012-11-01 18:48 ` [gentoo-python] Re: [PATCH eselect-python 1/2] Store per-version interpreter preference in a file as well Mike Gilbert
2012-11-01 20:59 ` Michał Górny
2012-11-01 21:27 ` Michał Górny
2012-11-01 22:42 ` Brian Harring
2012-11-02 9:03 ` Michał Górny
2012-11-03 3:35 ` Brian Harring
2012-11-03 7:33 ` Michał Górny
2012-11-03 11:47 ` Brian Harring
2012-11-03 15:55 ` Mike Gilbert
2012-11-03 21:31 ` Brian Harring [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121103213112.GB3150@localhost \
--to=ferringb@gmail.com \
--cc=floppym@gentoo.org \
--cc=gentoo-python@lists.gentoo.org \
--cc=mgorny@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox