eselect python can be used to switch the main python interpreter system-wide, but there seems to be no way to override that setting on a per-user or per-process level. The /usr/bin/python script itself can be overridden using the EPYTHON environment variable (although that doesn't seem to be documented and therefore might be unadvisable outside ebuilds), but many wrapper scripts don't honour that variable but call "eselect python show" instead. Examples include cython or twistd, and in fact anything generated from python_generate_wrapper_scripts. It would be nice if one could set one single environment variable to choose a given python version in all the places where such a choice can be made. Perhaps the override should be weak: if the wrapped application doesn't support the requested python version, execute the default python version instead. But in cases where it does exist, use the environment override in preference to the system-wide default. Issues related to this have been observed in two places related to sage: https://github.com/cschwan/sage-on-gentoo/pull/48 https://github.com/cschwan/sage-on-gentoo/issues/51#issuecomment-1042812 The common factor in these instances is that when building an application for a single python version only, there should be a way to have all build tools use that python version, and to use that version when calling python applications at runtime. Compare this to java stuff, where exporting GENTOO_VM can affect the behaviour of many applications, including e.g. ant. OK, there is a catch: Java doens't have to compile and install multiple versions, but only to switch runtime environment.
There is one simple way: elmer ~ # python -V Python 2.7.1 elmer ~ # alias python=/usr/bin/python3.1 elmer ~ # python -V Python 3.1.3
(In reply to comment #1) > There is one simple way: > elmer ~ # alias python=/usr/bin/python3.1 Aliases are for the current shell only. They won't influence wrapper scripts, and they won't influence python processes invoked (directly or indirectly) by some other python script, or any other process. Therefore the solution has to be based on environment variables, which are inherited, not on aliases.
Well, the new ebuilds based on python-exec always respect EPYTHON. Is that enough to consider this one fixed?
(In reply to comment #3) > Well, the new ebuilds based on python-exec always respect EPYTHON. Is that > enough to consider this one fixed? Is it documented? If so, I'm satisfied and hope packages will move to those new scripts soon. On my system, cython already has moved, twisted not yet.
Well, python-r1 is now fully in charge, so closing this as FIXED.
