1 |
On Thu, 18 Oct 2012 02:15:43 -0700 |
2 |
Brian Harring <ferringb@×××××.com> wrote: |
3 |
|
4 |
> There's a trick to this; currently, those generated scripts hardcode |
5 |
> the allowed/known python versions for that package. We obviously have |
6 |
> to preserve that; I propose we shove it into the symlink path. |
7 |
> |
8 |
> Basically, we add a /usr/libexec/python directory; within it, we have |
9 |
> a wrapper binary (explained below), and a set of symlinks pointing at |
10 |
> the root of that directory. To cover our current python versions, the |
11 |
> following would suffice: |
12 |
> |
13 |
> for x in {2.{4,5,6,7},3.{0,1,2,3,4}}-cpy 2.5-jython 2.7-pypy-1.{7,8} |
14 |
> \2.7-pypy-1.9; do |
15 |
> ln -s ./ /usr/libexec/python/$x |
16 |
> done |
17 |
> |
18 |
> While that seems insane, there is a reason; via that, we can encode |
19 |
> the allowed versions into the symlink. Using pkgcore's pquery for |
20 |
> example (which should support cpy: 2.5, 2.6, 2.7, 3.1, 3.2, 3.3) |
21 |
> instead of a wrapper script at /usr/bin/pquery, we'd have thus: |
22 |
> |
23 |
> targets=( 2.{5,6,7}-cpy 3.{1,2,3}-cpy ) |
24 |
> targets=$(IFS=/;echo -n "${targets[*]}") |
25 |
> # This results in |
26 |
> # targets=2.5-cpy/2.6-cpy/2.7-cpy/3.1-cpy/3.2-cpy/3.3-cpy |
27 |
> ln -s "/usr/libexec/python/${targets}/wrapper" \ |
28 |
> /usr/bin/pquery |
29 |
> |
30 |
> /usr/libexec/python/wrapper upon invocation, takes a look at argv[0]; |
31 |
> sees how it was invoked basically. This will be the /usr/bin/whatever |
32 |
> pathway. It reads the symlink, in the process getting the allowed |
33 |
> versions and preferred order of the versions. |
34 |
> |
35 |
> Few notes; vast majority of filesystems will store the symlink target |
36 |
> into the core inode if at all possible- in doing so, this avoids |
37 |
> wasting an inode and is only limited by the length of the target. |
38 |
> That length is capped by PATH_MAX- which can range from 256 to 4k (or |
39 |
> higher). |
40 |
> |
41 |
> For the pquery example above, that comes out to ~73 bytes for the |
42 |
> symlink pathway; well under PATH_MAX. |
43 |
> |
44 |
> For the scenarios where PATH_MAX caps the symlink pathway, or for |
45 |
> whatever reason we don't want to use that trick, a tree of files |
46 |
> contained within /usr/libexec/python/ holding the allowed versions for |
47 |
> the matching pathway would suffice. |
48 |
|
49 |
While I agree that it's a clever trick, I doubt it's worth the effort. |
50 |
Did you got any numbers proving it being superior over, say, trying to |
51 |
exec() scripts like I do in python-exec? |
52 |
|
53 |
While I can imagine, that in an worst case that bunch of exec()s is |
54 |
going to be definitely slower than storing the list anyway, I doubt |
55 |
such a bad case is often. |
56 |
|
57 |
Considering that the most common Python version used now is Python 2, |
58 |
how often doesn't the script support that Python version? That's a very |
59 |
rare case, and often just executing "foo-${EPYTHON}" works. In your |
60 |
case, that common case involves readlink() + parsing + exec(). |
61 |
|
62 |
Even in case of Python 3 being selected, I doubt the overhead |
63 |
of multiple exec()s on the scripts not supporting Python 3 is really |
64 |
relevant. Please measure it if you believe so. |
65 |
|
66 |
To be honest, I don't see any real advantage in this solution. It is |
67 |
complex; understanding it requires explanation or some thinking. |
68 |
The code will be fragile, and I'm not even sure if I'm not missing |
69 |
something important here. |
70 |
|
71 |
Thus, unless you've got a good arguments how this solution is superior |
72 |
to the straightforward one done in python-exec, or numbers proving that |
73 |
it is more efficient in a way noticeable to our users, -1. Smart hack, |
74 |
yes, but not really beneficial. |
75 |
|
76 |
> Either proposal here would be far faster than what we've got now; also |
77 |
> will use less space (ancillary benefit). |
78 |
> |
79 |
> One subtle aspect here is that if we did this, it makes it possible to |
80 |
> avoid losing the invocation information- currently if you did |
81 |
> `/usr/bin/python3.2 $(which sphinx-build) blah`, because of how things |
82 |
> are implemented now (specifically the two layers of wrappers)- you'll |
83 |
> get python2.7 running that sphinx-build invocation. |
84 |
> |
85 |
> This is wrong (it's directly discarding what the invocation |
86 |
> requested), although you're only going to see it for scripts that |
87 |
> do python introspection. |
88 |
> |
89 |
> Via doing the restructuring I'm mentioning above, that issue can be |
90 |
> fixed, while making things faster/saner. |
91 |
|
92 |
I don't see how this is relevant to the wrapper. As Mike pointed out, |
93 |
python3.2 is the actual Python executable, and the wrapper you're |
94 |
suggesting is a C executable -- something that does not really work |
95 |
together like that. |
96 |
|
97 |
So please elaborate on how you are actually going to solve this. Hope |
98 |
it's not through patching Python... |
99 |
|
100 |
-- |
101 |
Best regards, |
102 |
Michał Górny |