My system has the python-2.7 as the default python environment. The installed python-3 was never the default python interpreter, thus almost no python modules have been built and installed in /usr/lib64/python3.2/site-packages/. Today i tried to emerge dev-python/jinja, but the build of dev-python/markupsafe (dependency of jinja) failed to build with python-3.2 (because of the new PYTHON_TARGETS features) with the following error: cat /var/tmp/portage/dev-python/markupsafe-0.15/temp/build.log: ...snip snap... * Building of dev-python/markupsafe-0.15 with CPython 3.2... python3.2 setup.py --with-speedups build -b build-3.2 Traceback (most recent call last): File "setup.py", line 3, in <module> from setuptools import setup, Extension, Feature ImportError: No module named setuptools The setuptools was never build with python-3 so it's obviously why the distutils part of the ebuild failes. I re-emerged setuptools and the build completed (because setuptools is now available for py-3). The markupsafe ebuild specifies dev-python/setuptools in DEPEND. Imho portage should expand this dependency for all PYTHON_TARGETS. Im my situation the dependency tree should look like: dev-python/jinja: python-2.7: dev-python/setuptools: fullfilled dev-python/markupsafe: Needs to be emerged dev-python/setuptools: fullfilled .... python-3.2: dev-python/setuptools: Needs to be emerged (because it hasn't been build for 3.2 before) dev-python/markupsafe: Needs to be emerged (not installed) dev-python/setuptools: Needs to be emerged (because it hasn't been build for 3.2 before) .... This would drastically reduce the number of bugs filed due to missing modules for a specific python interpreter. The other way is to force the user to rebuild all installed python packages after changing the PYTHON_TARGETS to let portage rebuild the packages. Reproducible: Always Steps to Reproduce: 1. setup a system with python-2 only (or restrict the PYTHON_TARGETS to a single python interpreter) 2. install something that depends on setuptools (setuptools gets installed for py-2 only) 3. Install python-3 4. unset PYTHON_TARGETS if set 5. Emerge some package which also depends on setuptools and you will see the error above
I'm afraid there's practically no really good way of achieving this without migrating the all relevant ebuilds. However, I think there's one thing we could do. We can make python.eclass either respect or at least check PYTHON_TARGETS before falling back to its defaults.
I can't find a good enough resolution for this bug, but it is as following: 1) python-r1 (new) packages use correct dependencies whenever possible. We have a QA tool to look for invalid deps already, so everything is going to eventually be fixed. 2) python-r1 packages try to find out whether old (python.eclass) packages have correct settings and warn you if they don't. It's not perfect, it simply can't be but I think it's good enough for most of our users. Feel free to reopen if you believe something else needs being addressed.
