On Thu, Oct 18, 2012 at 11:28:59AM -0400, Mike Gilbert wrote: > On Thu, Oct 18, 2012 at 5:15 AM, Brian Harring <[email protected]> wrote: > If we are somehow going to eliminate the installation of a separate > script for each python version, then the symlink idea sounds like a > good solution for expressing the supported python versions. However, > I'm really not sure how you would eliminate the separate scripts, in > light of the 2to3 issue.
The elimination is just a dedup run; track the PYTHON_ABI script's being installed- check the md5 (minus the shebang). If it's the same, they can be hardlinked together with the appropriate shebang wrapper. It's doable, is the short version. Matter of fact, the dedupe run there could be extended to do deduplication in general across python versions, but that's an optimization for further down the line. > 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. > Back to the discussion djc pointed out: mgorny has implemented a > binary solution already, called "python-exec", in conjunction with > python-r1.eclass. > > https://bitbucket.org/mgorny/python-exec Another one I didn't see in the ML emails... joy. This is partial. Finishing this to what I'm proposing above isn't too hard to do however- that said, I strongly believe this doesn't belong in a separate repo/package, this should be shoved into eselect-python. eselect-python already gives us python-wrapper after all; no point in having two layers of wrappers, and content in two repos. > python-exec assumes there will be a separate script for each version, > and just calls exec several times. In shell code, it would look like > this: > > scriptname=$0 # argv[0] > exec scriptname-${EPYTHON} > exec scriptname-$(< /etc/env.d/python/config) > for x in python2.7 python2.6 python3.2 python3.1 ... ; do > exec scriptname-${x} > done > > The list of implementations for the loop at the end is hard-coded when > python-exec is built. This is the weak point in the solution. It could > be improved with your symlink idea. > > What are your thoughts on mgorny's python-exec solution? Code's a bit raw, but as I mentioned in my other email, it's on a similar path to what I'm proposing- same core idea, just specifics in mine + the symlink trick. > We could adapt it for python.eclass if you really want to support > that. Probably by modifying python.eclass to install scripts like > sphinx-python2.7 instead of sphinx-2.7. Honestly, w/ what I'm intending, we don't need to change the python eclass much- we can preserve the same naming in use if desired. If a rename is desired, sure, do it when this is phased in. That said if there isn't a reason for the rename, then don't do it, imo. ~harring
