1 |
On Thu, Oct 18, 2012 at 11:28:59AM -0400, Mike Gilbert wrote: |
2 |
> On Thu, Oct 18, 2012 at 5:15 AM, Brian Harring <ferringb@×××××.com> wrote: |
3 |
> If we are somehow going to eliminate the installation of a separate |
4 |
> script for each python version, then the symlink idea sounds like a |
5 |
> good solution for expressing the supported python versions. However, |
6 |
> I'm really not sure how you would eliminate the separate scripts, in |
7 |
> light of the 2to3 issue. |
8 |
|
9 |
The elimination is just a dedup run; track the PYTHON_ABI script's |
10 |
being installed- check the md5 (minus the shebang). If it's the same, |
11 |
they can be hardlinked together with the appropriate shebang wrapper. |
12 |
|
13 |
It's doable, is the short version. Matter of fact, the dedupe run |
14 |
there could be extended to do deduplication in general across python |
15 |
versions, but that's an optimization for further down the line. |
16 |
|
17 |
|
18 |
> Regarding your /usr/bin/python3.2 /usr/bin/sphinx-build example: |
19 |
> invoking python on a binary (or a symlink to a binary) isn't going to |
20 |
> work at all. So I don't see how you've solved that issue. |
21 |
|
22 |
Kindly provide reasoning/justification for such a claim in the future- |
23 |
saves a round of email ping/ponging, and saves me getting pissy |
24 |
towards people if they persist in it. :) |
25 |
|
26 |
Lecture aside, "nuh uh, it does work!" is appropriate. I already |
27 |
hacked up a prototype locally that works fine and does this via an |
28 |
env passing hack- w/ what was proposed, this can be done w/out those |
29 |
hacks, and would be faster. |
30 |
|
31 |
|
32 |
> Back to the discussion djc pointed out: mgorny has implemented a |
33 |
> binary solution already, called "python-exec", in conjunction with |
34 |
> python-r1.eclass. |
35 |
> |
36 |
> https://bitbucket.org/mgorny/python-exec |
37 |
|
38 |
Another one I didn't see in the ML emails... joy. This is partial. |
39 |
Finishing this to what I'm proposing above isn't too hard to do |
40 |
however- that said, I strongly believe this doesn't belong in a |
41 |
separate repo/package, this should be shoved into eselect-python. |
42 |
|
43 |
eselect-python already gives us python-wrapper after all; no point |
44 |
in having two layers of wrappers, and content in two repos. |
45 |
|
46 |
|
47 |
> python-exec assumes there will be a separate script for each version, |
48 |
> and just calls exec several times. In shell code, it would look like |
49 |
> this: |
50 |
> |
51 |
> scriptname=$0 # argv[0] |
52 |
> exec scriptname-${EPYTHON} |
53 |
> exec scriptname-$(< /etc/env.d/python/config) |
54 |
> for x in python2.7 python2.6 python3.2 python3.1 ... ; do |
55 |
> exec scriptname-${x} |
56 |
> done |
57 |
> |
58 |
> The list of implementations for the loop at the end is hard-coded when |
59 |
> python-exec is built. This is the weak point in the solution. It could |
60 |
> be improved with your symlink idea. |
61 |
> |
62 |
> What are your thoughts on mgorny's python-exec solution? |
63 |
|
64 |
Code's a bit raw, but as I mentioned in my other email, it's on a |
65 |
similar path to what I'm proposing- same core idea, just specifics in |
66 |
mine + the symlink trick. |
67 |
|
68 |
|
69 |
> We could adapt it for python.eclass if you really want to support |
70 |
> that. Probably by modifying python.eclass to install scripts like |
71 |
> sphinx-python2.7 instead of sphinx-2.7. |
72 |
|
73 |
Honestly, w/ what I'm intending, we don't need to change the python |
74 |
eclass much- we can preserve the same naming in use if desired. If a |
75 |
rename is desired, sure, do it when this is phased in. |
76 |
|
77 |
That said if there isn't a reason for the rename, then don't do it, |
78 |
imo. |
79 |
|
80 |
~harring |