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