1 |
On Sat, Nov 03, 2012 at 08:33:46AM +0100, Micha?? G??rny wrote: |
2 |
> On Fri, 2 Nov 2012 20:35:38 -0700 |
3 |
> Brian Harring <ferringb@×××××.com> wrote: |
4 |
> |
5 |
> > On Fri, Nov 02, 2012 at 10:03:05AM +0100, Micha?? G??rny wrote: |
6 |
> > > On Thu, 1 Nov 2012 15:42:42 -0700 |
7 |
> > > Brian Harring <ferringb@×××××.com> wrote: |
8 |
> > What I have written here is a python-shebang based solution. That |
9 |
> > shebang target includes the EPYTHON's it supports. |
10 |
> > |
11 |
> > For the usual sphinx-build example, sphinx-build-2.7 goes from |
12 |
> > #!/usr/bin/python2.7 |
13 |
> > |
14 |
> > to |
15 |
> > |
16 |
> > #!/usr/bin/python-shebang python2.7,python3.2 |
17 |
> > |
18 |
> > This means that sphinx-build-2.7 and sphinx-build-3.2 are now the same |
19 |
> > content. They can be hardlinked together (space savings). |
20 |
> > |
21 |
> > This additionally means that sphinx-build can be hardlinked to the |
22 |
> > same underlying inode. Why? Because python-shebang is smart enough |
23 |
> > to recognize the context it is invoked in. |
24 |
> > |
25 |
> > This additionally means that the follow commands: |
26 |
> > |
27 |
> > eselect python set 3.2 |
28 |
> > python2.7 /usr/bin/sphinx-build |
29 |
> > |
30 |
> > properly work- invoking sphinx-bulid in a 2.7 context (for anyone |
31 |
> > trying to write distutils/setup bits that aren't gentoo/EPYTHON |
32 |
> > specific, this is fricking useful to say the least). |
33 |
> |
34 |
> I think you've missed my question: what code does the 'sphinx-build' |
35 |
> contain, except for the shebang? Is that a Python version |
36 |
> of the wrapper? Some kind of os.exec()? |
37 |
|
38 |
Covered this in the email. |
39 |
|
40 |
As I said, if dedup'ing <script>-* results in the same |
41 |
content... then the wrapper as I said, is a hardlink to it. It's |
42 |
literally the script itself, no point in needing indirection since a |
43 |
$INTERP /usr/bin/sphinx-build would do the correct thing. |
44 |
|
45 |
If the content varies across the python interp specific scripts, then |
46 |
a simple wrapper transfers control back to shebang, passing on the |
47 |
forced interpretter. That wrapper is generated via thus: |
48 |
|
49 |
|
50 |
abi_list=python2.7,python3.2,etc,you,get,the,jist |
51 |
|
52 |
cat > wherever-to-write-the-wrapper << EOF |
53 |
#!$(type -P python-shebang) ${abi_list}${interpreter_args:+ ${interpreter_args}} |
54 |
import os, sys |
55 |
os.environ["EPYTHON"]=os.path.basename(sys.executable) |
56 |
targets="${abi_list}" |
57 |
if hasattr(os, "execvp"): |
58 |
os.execvp("python-shebang", [sys.argv[0], targets] + sys.argv) |
59 |
import subprocess |
60 |
sys.exit(subprocess.Popen(["python-shebang", targets] + sys.argv).wait()) |
61 |
EOF |
62 |
|
63 |
|
64 |
> > > > Frankly, you should be looking at this imo, rather than trying |
65 |
> > > > standalone files. Yes, files is simpler- but you'll wind up sooner or |
66 |
> > > > later rebuilding it into what I already built out here. |
67 |
> > > |
68 |
> > > I think you are missing the point I'm raising here. Mostly because your |
69 |
> > > python-wrapper doesn't handle per-version preferences like python-exec |
70 |
> > > does, unless I'm missing something. |
71 |
> > |
72 |
> > You're misunderstanding what was written; hell, I even referenced |
73 |
> > that it supports EPYTHON preference in #5 (java-config cycle |
74 |
> > breaking). |
75 |
> |
76 |
> EPYTHON preference is rarely used by users. Users are using |
77 |
> eselect-python. And eselect-python uses two levels of preferences: |
78 |
> |
79 |
> 1. 'Main' python interpreter preference, |
80 |
> |
81 |
> 2. Per-Python2/Python3 interpreter preference. |
82 |
> |
83 |
> With the former being stored in a file, the latter in symlinks. |
84 |
> The goal of my patches were to store both in files so that the symlink |
85 |
> reading code could be removed to make the code simpler. |
86 |
|
87 |
I've yet to see a real world justification for #2 in terms of |
88 |
it actually being desirable. |
89 |
|
90 |
I've not supported #2 in python-shebang; that said if the python team |
91 |
(as a whole, not just mgorny yelling I didn't add it) wants it, it's |
92 |
quick to add the support and requisite tests. See my comments further |
93 |
down however, I strongly think such control is incorrect. |
94 |
|
95 |
|
96 |
> > > > """ |
97 |
> > > > Add a python-shebang utility, slave python-wrapper to it. |
98 |
> > > > |
99 |
> > > > Going forward, the intent is to push the PYTHON_ABIs of a given |
100 |
> > > > script down into it's shebang, pointing the shebang at python-shebang. |
101 |
> > > > |
102 |
> > > > In this way, all known/supported abi's are available at the time of |
103 |
> > > > execution; further, if the target is told to respect-EPYTHON (meaning |
104 |
> > > > no searching for something to execute, either active python version or |
105 |
> > > > EPYTHON var), we can push this down into that list and have that code |
106 |
> > > > handle it. |
107 |
> > > > |
108 |
> > > > [...] |
109 |
> > > > |
110 |
> > > > to the simpler form of: |
111 |
> > > > for x in sphinx{,-{2.7,3.2}}; do echo > $x <<EOF |
112 |
> > > > #!/usr/bin/python-shebang python2.7,python3.2 |
113 |
> > > > <code> |
114 |
> > > > EOF |
115 |
> > > > done |
116 |
> > > |
117 |
> > > Hmm, are you assuming that /usr/bin/sphinx carries the actual code? |
118 |
> > > Or some special wrapper code? |
119 |
> > > |
120 |
> > > Not to mention you still bind the whole thing to installed package. |
121 |
> > > If you need to fix those files, you need to reinstall all packages |
122 |
> > > installing them. |
123 |
> > |
124 |
> > This critique makes no sense... and I'm pretty sure that any point you |
125 |
> > may manage to come up with, will apply directly to python-exec just as |
126 |
> > equally. |
127 |
> > |
128 |
> > Either clarify your claim, or drop the noise there. |
129 |
> |
130 |
> python-exec can't be executed like that currently, correct. By I can |
131 |
> make it so just by replacing the python-exec executable as the symlinks |
132 |
> will make it effectively to every single package. |
133 |
> |
134 |
> In your case, any change won't apply globally. |
135 |
|
136 |
This isn't much of a claimed con; yes, there is an API contract here. |
137 |
|
138 |
That's specifically that python-shebang is invoked w/ minimally two |
139 |
arguments; the first being the EPYTHON's for the intended target; the |
140 |
second being the intended target. |
141 |
|
142 |
That's it. Nothing more. As for "having to repair it"- were it |
143 |
required, it's easy enough to spot 'em (loop over vdb contents |
144 |
identifying files with /usr/bin/python-shebang as the shebang); that |
145 |
said, it's never going to be needed. |
146 |
|
147 |
|
148 |
> > > > The gains of this are thus: |
149 |
> > > |
150 |
> > > Could you please compare it to the modern solution (python-exec) rather |
151 |
> > > than the deprecated one? You are no longer on the uncharted waters. |
152 |
> > |
153 |
> > Respectfully, your 'modern solution' (vs deprecated) is purely in your |
154 |
> > head; distutils/python eclasses of your making aren't the tree. |
155 |
> > |
156 |
> > They're your playground right now- one that you're pushing, but I've |
157 |
> > yet to see real traction on. That's just reality; you may think it's |
158 |
> > a done deal (or will be), but the on the ground reality right now- |
159 |
> > including the pushback you've been getting from people in certain |
160 |
> > cases- makes me unwilling to pin my hopes on your work. |
161 |
> |
162 |
> It is just a difference in methods. You want to push your solution to |
163 |
> the whole tree at once and see what happens next. I rather prefer |
164 |
> testing it on new ebuilds first, then getting it stable and thinking |
165 |
> about replacing the old one when the new one is ready. |
166 |
|
167 |
Mgorny, quit it with the insinuations that I'm not paying attention to |
168 |
QA. |
169 |
|
170 |
My solution doesn't break existing deployment, has tests, and |
171 |
actually works; yours breaks real world usage already and requires |
172 |
arbitrary renaming of scripts... which can induce it's own breakage |
173 |
(any script that know to find a python2.7 version of a script at |
174 |
<script-name>-2.7 would break). |
175 |
|
176 |
Minimally, any solution pushed is going to require QA; this includes |
177 |
validating the implementation (already got that covered), and full |
178 |
scale testing (which I've already been doing locally as initial |
179 |
steps). |
180 |
|
181 |
Find it funny you claim I'm just trying to jam it into the tree; |
182 |
deployment of this wasn't mentioned since I've not finished it in full |
183 |
yet. |
184 |
|
185 |
Beyond local testing and tinderbox runs, the rough deployment plan |
186 |
in my head is thus; it's fairly cautious additionally: |
187 |
|
188 |
1) add a use flag (defaulted off) that turns on the new implementation |
189 |
2) Nudge adventurous folk to flip it on and get more testing |
190 |
3) Minimally get prefix involved since if there are issues, it'll come |
191 |
from them; get them converted over. |
192 |
4) Bug rate hits zero, drop the flag and make it the new norm for |
193 |
python.eclass and your 8 ebuilds. |
194 |
|
195 |
|
196 |
> > Either way, you asked, so here's the list of python-exec con's in |
197 |
> > comparison to python-shebang: |
198 |
> > |
199 |
> > 1) Your solution actually doesn't work as a fricking wrapper for a |
200 |
> > core usage case; `python /usr/bin/sphinx-build`. That perfectly |
201 |
> > innocuous/valid invocation would result in the interpretter trying |
202 |
> > to execute an elf binary. That pretty much renders your solution as a |
203 |
> > no go right from the get go. Your only way to fix that is to have |
204 |
> > sphinx-build be a python implementation that does wrapping, and use a |
205 |
> > shebang of python-exec (so you can maintain speed for direct |
206 |
> > /usr/bin/sphinx-build invocations); meaning once you spotted that |
207 |
> > flaw, you'd evolve your attempt into something nearing what I wrote. |
208 |
> |
209 |
> No, not really. I still am afraid that you're missing some point of how |
210 |
> Python interpreter works but considering the fight you put protecting |
211 |
> 'python /usr/bin/c-file', I won't continue that topic until you finally |
212 |
> answer my questions wrt that file. |
213 |
|
214 |
Either your english sucks, or you're not understanding your proffered |
215 |
solution doesn't work... or you're not going to acknowledge it |
216 |
doesn't actually work. Honestly not sure which considering the |
217 |
insanity of your claims here. |
218 |
|
219 |
You propose, using trial for this example, to have trial-{2.7,3.1,3.2} |
220 |
be interpretter specific versions of the script, and and to ln -s |
221 |
/path/to/python-exec /usr/bin/trial |
222 |
|
223 |
That means /usr/bin/trial is an elf binary. |
224 |
|
225 |
This means, regardless of what crack-adled fricking claim you make |
226 |
about my cpython knowledge... python /usr/bin/trial, which resolves |
227 |
to, `python /usr/bin/python-exec`... ain't going to work. Ever. |
228 |
Never ever. |
229 |
|
230 |
Ironically, floppym pointed out this sort of flaw in my initial brain |
231 |
dump of a symlink approach (which lead to the python-shebang |
232 |
approach, emails you responded to but aparently didn't fix in your |
233 |
own proposal). You were active in that thread, trying pretty heavily |
234 |
to call the proposal hack/horrible/crappy/a meany, you should've |
235 |
caught this flaw and dealt w/ it in your own implementation. |
236 |
|
237 |
|
238 |
> By the way, I doubt it is a 'core usage case'. Maybe just because it |
239 |
> never worked as intended, maybe because people simply don't do that |
240 |
> usually because people usually don't care whether stuff in /usr/bin |
241 |
> is Python, C or shell. |
242 |
|
243 |
re-execing and invoking scripts w/in a source via using sys.executable |
244 |
is standard. If in doubt, go sample the python universe. Hell, think |
245 |
through standard re-exec; what you've got implemented here doesn't |
246 |
preserve argv[0] as the raw script name (which is a regression from |
247 |
existing solutions); were it to do so, you'd be triggering this fault |
248 |
via re-exec. |
249 |
|
250 |
Even if you wanted to make such a claim, you're ignoring that python |
251 |
/usr/bin/trial works *now*, and you'd be breaking that. Meaning |
252 |
minimally a regression of what frankly, is insane to break (perl |
253 |
/usr/bin/spamassassin shouldn't fail anymore than python |
254 |
/usr/bin/emerge should fail). |
255 |
|
256 |
|
257 |
> > 2) Everytime there is a new python interpretter, python-exec has to |
258 |
> > be re-built updating it's hardcoded list of interpretters. Goes without |
259 |
> > saying, this sucks a fair bit; your solution there likely would be |
260 |
> > walk env.d/python/* in some fashion extracting the list of targets (or |
261 |
> > walk /usr/bin/python* and run into problems w/ the names used there |
262 |
> > now matching EPYTHON usage). End result, you'd evolve it into |
263 |
> > something nearing what I did w/ shebangs. |
264 |
> |
265 |
> How often does this happen? Is this really problematic? |
266 |
|
267 |
It's a sign that your solution is hacky, frankly. |
268 |
|
269 |
We shouldn't have to rebuild binaries for configuration data |
270 |
changing- you may not like it, but that's usually a sign of bad code. |
271 |
|
272 |
|
273 |
> And how an user can disable a particular (say, problematic) Python |
274 |
> implementation globally in your solution? Without reinstalling all |
275 |
> the packages which provide scripts for it? |
276 |
|
277 |
Depends on your definition of 'disable'. With your solution, the only |
278 |
way to disable the interpretter in question is thus |
279 |
|
280 |
1) Unmerge the interpretter |
281 |
2) mangle the python abi list for python-exec via rebuilding it. |
282 |
|
283 |
However. #2 carries with it one helluva of an unstated gotcha; that |
284 |
every single time the available interpretters change, it has to be |
285 |
recompiled, or the full list of targets has to be passed in every |
286 |
time. Both of those are arbitrary... lets call it 'hobbiest' |
287 |
limitations that aren't production worthy. |
288 |
|
289 |
Either way, in my solution, if we wanted users to be able to have |
290 |
pypy-1.8 installed, have things compiled for it, but blacklist it |
291 |
after the fact (while leaving the interpretter installed) I'd just add |
292 |
a file into env.d listing the blacklisted interpretters, and update |
293 |
python-shebang accordingly. |
294 |
|
295 |
Keep in mind since the patchset targets python-eselect, deploying that |
296 |
is an easy shot. |
297 |
|
298 |
I'm not particularly convinced you're presenting a real world |
299 |
scenario however. Regardless, it's easily addressed via my solution. |
300 |
|
301 |
|
302 |
> > 3) It's a hardcoded lookup list that is forced for all scripts; if |
303 |
> > that list is python3.2,python3.1,python2.7, and the active python |
304 |
> > version doesn't intersect that (say jython-2.5), your approach forces |
305 |
> > 3.2. My solution actually allows the script, in the absense of an |
306 |
> > enforcement via active python or EPYTHON, to use it's own preferred |
307 |
> > ordering. Using pkgcore as an example, we prefer py2k execution over |
308 |
> > py3k- py2k is faster since the extensions are enabled. This |
309 |
> > capability doesn't exist in your solution, nor the existing wrapper; |
310 |
> > it's a useful byproduct of how my solution is structured. Etc etc, |
311 |
> > you know the response; where you'll go with this sooner or later is |
312 |
> > where python-shebang is already. |
313 |
> |
314 |
> And, hmm, are you the first person requesting such a feature over |
315 |
> the whole lifetime of python-wrapper? |
316 |
|
317 |
I'm the first person who got pissed enough to address it. Most of the |
318 |
time it works fine- but when you invoke something like trial or |
319 |
sphinx-build, things that analyze *other* python namespaces, it |
320 |
breaks. |
321 |
|
322 |
It's inarguably broken; arfrever's proposed solution to it when I |
323 |
pointed it out was to hardcode gentooisms into the solution- I don't |
324 |
agree with that, fix it properly as I've done. |
325 |
|
326 |
|
327 |
> I believe that hardcoded list is *simpler*. If user enabled jython-2.5 |
328 |
> (suicidal type?), then he's aware of the consequences. And in my |
329 |
> solution, preferred Python 2 will be used. Then preferred Python 3. |
330 |
> Then Python 2.7, 2.6, 2.5... then 3.2. It is predictable. |
331 |
> |
332 |
> In your solution, it is completely unpredictable. Developer can |
333 |
> (supposedly) do whatever he wants. Most of the devs probably won't use |
334 |
> that, except for a few cases where users will simply hit (if ever) |
335 |
> an unexpected behavior. |
336 |
|
337 |
Fact is, the option is opened up via the shebang approach to solving |
338 |
this. |
339 |
|
340 |
You're advocating that the fallback choice should be user controlled. |
341 |
Frankly... that's the wrong approach. |
342 |
|
343 |
If a script is invoked- offlineimap, iotop, cvs2*, btrfs-bcp, |
344 |
revdep-rebuild, etc; the user actually rarely cares which |
345 |
implementation is used. Up front, they decided which implementations |
346 |
they wanted to allow- but w/in that, sans the active interpretter, |
347 |
the user does not *care*. |
348 |
|
349 |
That's just fact. A user won't give a shit if it's offlineimap 2.7 or |
350 |
offlineimap 3.2. The implementation however *may* have a preference |
351 |
there- pkgcore/snakeoil aren't the only pkgs that have py2k extensions |
352 |
but not py3k extension. If you looked at that level of python, you'd |
353 |
recognize the API changes weren't exactly minor. Doable, but a pita. |
354 |
|
355 |
The kicker here is if we wanted users to be able to override the |
356 |
defaults... it's doable with my solution; just extend python-shebang. |
357 |
|
358 |
That said, your solution provides no way to enumerate the pkgs own |
359 |
preferences- not without shoving that information into a new file |
360 |
(yet another file required in comparison to my solution). |
361 |
|
362 |
|
363 |
> > 5) Via going with a standalone package from eselect-python, you're |
364 |
> > introducing the potential for the two to be out of sync/incompatible. |
365 |
> > Addressable via folding it inline into eselect-python (as I did), but |
366 |
> > it's a con against your solution in it's current claimed form. Same |
367 |
> > thing, you'll do what I did sooner or later since it's the better |
368 |
> > approach. |
369 |
> |
370 |
> It's a better development practice to split things. |
371 |
> You should've known that by now. |
372 |
> In any case, python-exec can work *without* |
373 |
> eselect-python. You can try it if you don't believe. |
374 |
|
375 |
I didn't claim it couldn't; I'm pointing out such a separation has no |
376 |
gain, but has costs. |
377 |
|
378 |
Python-wrapper already exists in python-eselect; python-wrapper is |
379 |
dependent on the internal details of how eselect python stores it's |
380 |
configuration. This is fine- python-wrapper can be kept lockstep up |
381 |
to date with eselect pythons internals. |
382 |
|
383 |
Your solution however cannot be, not without leveling deps to force it |
384 |
to be lock step (and the transition there will require compatibility |
385 |
code left in eselect python). If you don't see this, then I suggest |
386 |
you try modifying eselect python to move the config file, or change |
387 |
the semantics of how/what it stores. |
388 |
|
389 |
Regardless, there's zero reason to separate them. Separation is done |
390 |
when it makes sense, not for random shits and giggles. |
391 |
|
392 |
python-shebang is effectively a generalized/sane python-wrapper; |
393 |
python-wrapper itself is just a re-exec to python-shebang after all. |
394 |
The proper place, and the place it will wind up at (regardless of your |
395 |
bitching) is eselect python. |
396 |
|
397 |
|
398 |
> > 7) My solution doesn't hardcode /usr/bin/* pathways. User sticks a |
399 |
> > python2.7 into /usr/local/ (for whatever reason they choose to do so), |
400 |
> > it will honor that. |
401 |
> |
402 |
> Errr? Where does your suggestion come from? |
403 |
> |
404 |
> As far as I'm aware, user can put into per-implementation copy whatever |
405 |
> he wants. Including a shell script, a C executable or whatever. It will |
406 |
> work. |
407 |
|
408 |
Your solution is reliant on the hardcoded shebang w/in each script; |
409 |
meaning /usr/bin/python* or whatever it may be. |
410 |
|
411 |
Literally, sphinx-build-2.7, it has the hardcoded pathway |
412 |
#!/usr/bin/python2.7 |
413 |
|
414 |
Now, if you wanted that to not be hardcoded, it would be |
415 |
#!/usr/bin/env python2.7 |
416 |
|
417 |
But in doing so, you no longer can pass arguments to the interpretter. |
418 |
|
419 |
> With your, it won't. |
420 |
|
421 |
If you're going to make such claims, at least bother to read the |
422 |
source please. My solution searches path; meaning if it's trying to |
423 |
find python2.7, it'll search the path for it (same basic logic |
424 |
python-wrapper uses). |
425 |
|
426 |
Kicker is, it's a minor point in favor of python-shebang. Can either |
427 |
ignore the point, or make it into a bigger issue... your choice. |
428 |
|
429 |
|
430 |
> As far as I'm aware, you solution can't handle per-implementation |
431 |
> Python options (command-line arguments) either. In mine, it's as simple |
432 |
> as dropping them onto the shebang. |
433 |
|
434 |
If you'd read the email you're responding to, you'd see that per |
435 |
implementation python options are supported- and work fine now. |
436 |
|
437 |
Look at the arg parsing bit I posted; or go read the !#@*ing source |
438 |
already rather than immediately clicking reply. |
439 |
|
440 |
|
441 |
> > 8) Your solution doesn't work in the context of being used for |
442 |
> > /usr/bin/python wrapper; it's close, but as you yourself said, it |
443 |
> > requires symlinks (python-python2.7). |
444 |
> |
445 |
> Or adding a conditional which your solution simply does. So, where are |
446 |
> you going with this point? To the fact that I'm asking others for |
447 |
> opinion while you're ignoring their existence? |
448 |
|
449 |
What conditional am I adding? |
450 |
|
451 |
Your solution isn't usable *now* as a drop in for python-wrapper; it |
452 |
would have to be python-python2.7. |
453 |
|
454 |
In the same vane, you're implementation actually requires scripts to |
455 |
be named trial-python2.7 trial-python3.2 etc. |
456 |
|
457 |
That's not "asking peoples views"; that's the reality of your |
458 |
implementation. |
459 |
|
460 |
|
461 |
> > 9) No tests. Every. Fucking. Pathway. is tested with what I wrote. |
462 |
> > Python-exec lacks that, else issue #1 would've been spotted up front. |
463 |
> |
464 |
> Great. Awesome. You are so awesome I can't even spell it. |
465 |
> |
466 |
> Now feel free to grep the bugzie. That 'issue #1' is known. So far, |
467 |
> I haven't get anyone to say he believes that's really important |
468 |
> or useful. |
469 |
|
470 |
Your implementation mandates the following: |
471 |
|
472 |
*) scripts be changed from sphinx-build-2.7 to sphinx-build-python2.7. |
473 |
|
474 |
*) mandates symlinks of python-EPYTHON were it to be attempted to be |
475 |
used for python-wrapper. |
476 |
|
477 |
*) removes the ability to do $PYTHON_INTERP /usr/bin/script |
478 |
|
479 |
These are the sort of things that would've been identified with tests. |
480 |
|
481 |
Meaning you're "lets start using python-exec" emails would've been a |
482 |
helluva lot more accurate in those cases. |
483 |
|
484 |
|
485 |
Pretty much, thus: |
486 |
*) python-exec regresses from existing standard wrapper- you no longer |
487 |
can do python /usr/bin/sphinx-build and it requires a recompile |
488 |
everytime a new python interpretter is installed. |
489 |
*) python-shebang has no regressions from the standard, fixes the |
490 |
python2.7 /usr/bin/sphinx-bulid scenario, and decreases the number of |
491 |
files on disk. |
492 |
|
493 |
pretty much, that's the end of conversation with you mgorny. |
494 |
|
495 |
Python herd, assuming you've not ignored the thread due to the noise, |
496 |
your views would be useful. |
497 |
~harring |