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

[Brian Harring]

On Thu, Oct 18, 2012 at 08:02:42AM -0700, Brian Dolbec wrote:
> On Thu, 2012-10-18 at 02:15 -0700, Brian Harring wrote:
> > On a related note; we currently install multiple versions of the same
> > script- the only difference being the shebang.  If one ignores the
> > shebang, in some cases this is necessary- where the script is 2to3
> > translated, and the code for py2k vs py3k differs.  For most, the only
> > difference is in the shebang however.
> >
>
> What if the invoking script is not needed to be 2to3 translated (super
> minimal python code) but the remaining python libs need to be?

Then we dedup 'em, using a shebang that knows to look at argv[0]'s 
last few chars to find the appropriate python binary to invoke via.

As for the installation- either hardlinked'd scripts, or symlinked; 
doesn't really matter, although hardlink gets my vote (so 
sphinx-build-2.7 would be a hardlink to the same inode as 
sphinx-build-3.2).

> > While it's minor in space savings, it's possible to eliminate that
> > redundancy via a shebang target that looks at the pathway it was
> > invoked via.  Fairly easy actually, and basically zero overhead if
> > done.
> >
> > Either way, thoughts?
> >
> > What I'm proposing isn't perfect, but I'm of the view it's a step up
> > from what's in place now- and via centralizing this crap, makes it
> > easier to change/maintain this going forward as necessary.
> > ~harring
> >
>
> +1 from me.
>
> Eclean has been checking the name it was invoked with long before I did
> the major re-write.  From that it cleans either distfiles or packages if
> invoked by either the eclean-dist or eclean-pkg symlinks.  If invoked by
> eclean itself then it looks for the target in the arguments.  So Brian's
> proposal is not something totally new, never been done before...
>
> While this proposes something a little different.  It is still very much
> along the same line and in my opinion a much better solution.

Regarding "having the script check on it's own"... yeah, this has been 
on pkgcore's todo for a while, but basically got blocked by the 
current wrapper bits.  I expect once this wrapper is in place, I may 
screw with the setup a bit to find a way so that scripts that can 
handle this on their own, are left to handle this on their own.

Any other +1's/-1's?  Else I may do this on the weekend for 
destress-hacking time...

~harring