[gentoo-dev] Re: reworking python-wrapper and wrapper scripts.

[Brian Harring]

On Thu, Oct 18, 2012 at 04:50:04PM -0400, Mike Gilbert wrote:
> On Thu, Oct 18, 2012 at 3:29 PM, Brian Harring <ferringb@×××××.com> wrote:
> > On Thu, Oct 18, 2012 at 11:28:59AM -0400, Mike Gilbert wrote:
> >> Regarding your /usr/bin/python3.2 /usr/bin/sphinx-build example:
> >> invoking python on a binary (or a symlink to a binary) isn't going to
> >> work at all. So I don't see how you've solved that issue.
> >
> > Kindly provide reasoning/justification for such a claim in the future-
> > saves a round of email ping/ponging, and saves me getting pissy
> > towards people if they persist in it. :)
> >
> > Lecture aside, "nuh uh, it does work!" is appropriate.  I already
> > hacked up a prototype locally that works fine and does this via an
> > env passing hack- w/ what was proposed, this can be done w/out those
> > hacks, and would be faster.
> >
>
> When you invoke a command like:
>
> /usr/bin/python3.2 /usr/bin/somebinary
>
> The python3.2 program assumes somebinary is a python script and tries
> to parse it. Since somebinary is actually an ELF object, python bombs
> out immediately.
>
> Am I missing something fundamental here?

Nope, you've got me embarassingly, absolutely fricking dead to rights 
on that one; I overlooked at the prototype I did was a python script 
for 'somebinary', which worked via the env passing.

Would've spotted it upon implementing it in c to say the least, but 
still, *cough*. ;)

As you mentioned in a separate email; if we stick a wrapper in front 
of the python binaries, that would fly; I don't much like that 
however.

Offhand... and this makes it a bit more complex, but still tenuable 
imo, but we could get around this via shoving the symlink pathway into 
the shebang itself.

scenario 1:
Script gets installed for 2.7, 3.1, 3.2; ignoring the shebang, it's 
exactly the same md5 (meaning we can dedup it).  The shebang instead 
of being /usr/bin/python-whatever, instead is the symlink pathway I'd 
referenced.  Meaning it would be 
/usr/libexec/python/2.7/3.1/3.2/wrapper .  If that script was 
sphinx-build, this means that sphinx-build{,-{2.7,3.1,3.2}} are all 
valid python scripts- they can be invoked either via /path/to/script 
or ${python} /path/to/script.  There's a few details to sort there, 
but nothing egregious best I can tell- implicit in this proposal is 
that the wrapper would be smart enough to tell in which context it's 
being invoked (sphinx-build vs sphinx-build-2.7).

Scenario 2:
2.7, 3.1, 3.2 are in play; they do /not/ dedupe to the same content, 
meaning we actually need indirection in 'sphinx-build' (but not 
sphinx-build-{2.7,3.1,3.2} although we would dedupe where possible 
mind you).

In that case, to support python3.2 sphinx-build, we'd need a python 
script that does the searching/re-exec for the wrapper.  This can be 
standardized- just have it search for sphinx-build-${PYTHON_ABIS} to 
identify the installed versions, then do the usual active 
version/epython trick to decide which to use.  This honestly isn't too 
far off from what we have now.

We can however optimize that; same trick, for the wrapper the shebang 
isn't /usr/bin/python; it's just a c version of the python script, 
done in c for speed.

So... caveats.  If we screw w/ the shebang like this, file isn't going 
to like it- it'll fail to identify certain scripts as python.  That 
said, it's worth keeping in mind that if we use the symlink route, a 
file /usr/bin/sphinx-build would result in ELF, vs file 
/usr/bin/sphinx-build-2.7 being python.

This can be fixed via an additional rule added to the magic db.  
Pretty straight forward, and eselect-python (once it gets these 
wrappers) could level an appropriate dep to ensure that's sorted.

So... my preference is shebang; it's basically an extension of the 
symlink trick I'd originally mentioned, just cleaner imo.

What are folks thoughts on that?
~harring