| Summary: | dev-python/python-exec: C-wrapper prohibits 'pythonX.Y foo' invocation | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Michał Górny <mgorny> |
| Component: | Current packages | Assignee: | Michał Górny <mgorny> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | python |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
Since this seems to be a very big deal for some people and Brian has tested a fairly good solution already, here's how I see we could fix it: 1. rename python-exec -> some-other-name, 2. install python-exec as a python script setting EPYTHON and doing re-exec with shebang running some-other-name directly. Unless I'm missing something, this should fix it sanely: 1. foo -symlink-> python-exec -shebang-> some-other-name, [no python involved in running] 2. python foo -symlink-> python python-exec -os.exec()-> some-other-name. @floppym, idella4: any comments? I'll try to implement it in a branch today afternoon. (In reply to comment #1) I'm not actually sure what you're proposing here, but I'm happy to review whatever you come up with. (In reply to comment #2) > (In reply to comment #1) > > I'm not actually sure what you're proposing here, but I'm happy to review > whatever you come up with. And it's ready on 'python-wrapper' branch! layman -a mgorny flaggie python-exec +** EGIT_BRANCH=python-wrapper emerge -1 python-exec python3.2 /usr/bin/flaggie (!) Or just: https://bitbucket.org/mgorny/python-exec/compare/python-wrapper.. Seems to work pretty well. One interesting behavior: If you invoke it using a python version for which there is no script-$EPYTHON, it falls back to the eselected version and/or iterating through all of them. (In reply to comment #4) > Seems to work pretty well. > > One interesting behavior: If you invoke it using a python version for which > there is no script-$EPYTHON, it falls back to the eselected version and/or > iterating through all of them. Yes, that was intended. I'm however wondering about two things: 1) using sys.executable... ...which is dumb path to the interpreter and contain just anything. I'm thinking about replacing that with something smart and simple -- like installing a custom Python module with EPYTHON written for import. 2) calling the wrapper directly instead of the wrapped script... ...which is somehow better but doesn't exactly follow the semantics of 'pythonX.Y /usr/bin/foo'. For example, it respects the interpreter options in shebang while the latter wouldn't. And your point also falls into this category. We might make it instead just choose foo-pythonX.Y, and execute that script using the current Python interpreter whatever it is. Fixed in 0.2. |
The C wrapper installed by python-exec and symlinked in place of Python scripts by distutils-r1 makes it impossible to invoke those scripts (without implementation suffix) through 'pythonX.Y', e.g.: $ python2.7 /usr/bin/flaggie File "/usr/bin/flaggie", line 1 ELF ^ SyntaxError: invalid syntax This is somehow a regression, you can tell, although running 'pythonX.Y /usr/bin/foo' wouldn't respect the given Python version AFAIK. Anyway, there are two questions: 1. Do we want to support such use? As in, do we really expect people doing 'pythonX.Y /usr/bin/foo' when they can just call /usr/bin/foo-pythonX.Y instead? 2. If we do, how can we solve that?