1 |
2009-12-21 11:50:14 Brian Harring napisaĆ(a): |
2 |
> On Sat, Dec 19, 2009 at 04:24:49PM +0100, Arfrever Frehtes Taifersar Arahesis wrote: |
3 |
> > Distutils/Setuptools/Distribute modify shebangs of installed Python scripts, so that they |
4 |
> > contain path of Python interpreter with version included (e.g. "#!/usr/bin/python3.2"). |
5 |
> > This behavior has both advantage and disadvantages: |
6 |
> > - Scripts of packages supporting only e.g. Python 2 can be executed (without necessity |
7 |
> > of using of e.g. "python2 /usr/bin/${script}") after activating of e.g. Python 3. |
8 |
> > - Scripts of packages supporting multiple Python versions ignore active Python version. |
9 |
> > - Scripts of packages supporting multiple Python versions cannot be easily (without |
10 |
> > necessity of using of e.g. "python3.1 /usr/bin/${script}") executed with a Python |
11 |
> > version different than active Python version. |
12 |
> > The best solution, which removes these 2 disadvantages and preserves the advantage, seems |
13 |
> > to be to rename Python scripts to include Python version [1] in filenames, and create wrapper |
14 |
> > scripts, which call appropriate target scripts [2]. Some files sometimes try to execute |
15 |
> > e.g. "/usr/bin/python /usr/bin/${script}", so wrapper scripts must be implemented in Python. |
16 |
> > Wrapper scripts try to execute "${wrapper_script}-${PYTHON_ABI}" files (e.g. "py.test" will |
17 |
> > execute "py.test-3.1", when Python 3.1 is set as active Python version). |
18 |
> > |
19 |
> > distutils.eclass will automatically rename some scripts [3] in "${D}usr/bin" and call |
20 |
> > the function, which generates wrapper scripts. In case somebody is interested in reading of |
21 |
> > source code of python_generate_wrapper_scripts() function and potential suggesting of |
22 |
> > improvements, I'm attaching this function and 2 example wrapper scripts. I'm planning to |
23 |
> > commit addition of this function in next week. |
24 |
> |
25 |
> Not really a huge fan of the EPYTHON var... can you clarify it's real |
26 |
> world usage? |
27 |
|
28 |
It simplifies development of ebuilds of packages having non-Distutils-based build systems. |
29 |
E.g. ebuilds of packages, which support only Python2, install some executables or libraries |
30 |
(e.g. /usr/lib/kvirc/4.0/modules/libkvipythoncore.so of net-irc/kvirc) linked against |
31 |
libpythonX.Y.so and don't install any Python modules, will be able to simply call |
32 |
'python_set_active_version 2', which will export EPYTHON variable with appropriate value. |
33 |
Ebuilds should never manually set EPYTHON variable. |
34 |
|
35 |
> I can see that causing all sorts of mayhem as it passes |
36 |
> it's way down through python scripts invoking other scripts- |
37 |
> specifically thinking of a py3k only script being forced to 3.1, then |
38 |
> invoking a py2k script. |
39 |
|
40 |
EPYTHON variable should be respected only by scripts, which are used during building, testing |
41 |
or installation of other packages and need to be called with appropriate Python version. |
42 |
Examples: py.test, trial |
43 |
distutils_src_install() will call python_generate_wrapper_scripts() (at least by default) |
44 |
without -E option. |
45 |
|
46 |
> Beyond that, please provide a way to *disable* this for a pkg. |
47 |
|
48 |
OK. |
49 |
|
50 |
-- |
51 |
Arfrever Frehtes Taifersar Arahesis |