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
