dev-python/Babel does not support python3 and is not easily fixable to do so. dev-python/jinja supports python3 and uses Babel optionally, with USE=i18n. Shortly saying, this means that with the python3 variant of jinja is less powerful than the python2 one which is not friendly to users.
What do you intend to do about it? I don't think this is a good enough reason to disabe i18n support completely (or default to it with py2?). I think this is an upstream bug, not much we can do about it.
The major problem here is that I don't know what to do about it. For build-time deps the resolution is simple as dbus-python ebuild shows: DEP=doc? ( epydoc[py2*] ) REQUIRED_USE=doc? ( || ( py2* ) ) For run-time, it's no longer that trivial. a) since it's just a virtual flag which doesn't actually change anything in the package, we could just ignore the problem and use plain dep; b) we could use REQ_USE like above to make sure that after disabling all py2 versions user would not end up without i18n actually, c) we could go even further and do: REQUIRED_USE=py3*? ( !i18n ) to make sure that user won't try to use version without i18n if he likes it. But it will haunt users using the default PYTHON_TARGETS. d) we could add a post-inst check for active Python version and warn when it's Python3 & i18n is enabled. Or warn generally when i18n is enabled.
Is this bug the reason for jinja-2.7 in tree being Py3k-incapable?
Jinja 2.7 dropped support for 3.2, and I didn't have 3.3 installed yet.
(In reply to comment #4) > Jinja 2.7 dropped support for 3.2 Oh blast. I knew it was a bad sign, moving development to github. Thank you for clarification.
Those things have nothing to do with each other. Armin just wrote a blog post with some very good rationale about why he dropped 3.2 (because it makes a 2.x + 3.x compatible codebase much easier).
This should be better now that we have Babel-1.2.
New versions are fixed
