1 |
On Sat, Dec 19, 2009 at 04:24:49PM +0100, Arfrever Frehtes Taifersar Arahesis wrote: |
2 |
> Distutils/Setuptools/Distribute modify shebangs of installed Python scripts, so that they |
3 |
> contain path of Python interpreter with version included (e.g. "#!/usr/bin/python3.2"). |
4 |
> This behavior has both advantage and disadvantages: |
5 |
> - Scripts of packages supporting only e.g. Python 2 can be executed (without necessity |
6 |
> of using of e.g. "python2 /usr/bin/${script}") after activating of e.g. Python 3. |
7 |
> - Scripts of packages supporting multiple Python versions ignore active Python version. |
8 |
> - Scripts of packages supporting multiple Python versions cannot be easily (without |
9 |
> necessity of using of e.g. "python3.1 /usr/bin/${script}") executed with a Python |
10 |
> version different than active Python version. |
11 |
> The best solution, which removes these 2 disadvantages and preserves the advantage, seems |
12 |
> to be to rename Python scripts to include Python version [1] in filenames, and create wrapper |
13 |
> scripts, which call appropriate target scripts [2]. Some files sometimes try to execute |
14 |
> e.g. "/usr/bin/python /usr/bin/${script}", so wrapper scripts must be implemented in Python. |
15 |
> Wrapper scripts try to execute "${wrapper_script}-${PYTHON_ABI}" files (e.g. "py.test" will |
16 |
> execute "py.test-3.1", when Python 3.1 is set as active Python version). |
17 |
> |
18 |
> distutils.eclass will automatically rename some scripts [3] in "${D}usr/bin" and call |
19 |
> the function, which generates wrapper scripts. In case somebody is interested in reading of |
20 |
> source code of python_generate_wrapper_scripts() function and potential suggesting of |
21 |
> improvements, I'm attaching this function and 2 example wrapper scripts. I'm planning to |
22 |
> commit addition of this function in next week. |
23 |
|
24 |
Not really a huge fan of the EPYTHON var... can you clarify it's real |
25 |
world usage? I can see that causing all sorts of mayhem as it passes |
26 |
it's way down through python scripts invoking other scripts- |
27 |
specifically thinking of a py3k only script being forced to 3.1, then |
28 |
invoking a py2k script. |
29 |
|
30 |
Beyond that, please provide a way to *disable* this for a pkg. At |
31 |
least for pkgcore, I've already been looking at ways to deal with |
32 |
this and would rather solve it at the pkg level (since EPYTHON let |
33 |
alone eselect may not exist for certain target deployments of |
34 |
pkgcore itself). |
35 |
|
36 |
Basically, no point in having wrapper scripts if the target already |
37 |
can do it's own version of this, hence wanting a way to disable it in |
38 |
the ebuild- that's just for the script mangling, library installing |
39 |
for multiple python abis is a seperate thing. |
40 |
|
41 |
Aside from that, punting on the re import might be nice primarily for |
42 |
speed reasons (no it's not a huge import in cost, but this is an extra |
43 |
~.025 per python script invoked, ignoring the ~.3 to ~.02 for eselect |
44 |
dependant on cache status). |
45 |
|
46 |
~harring |