Summary: | dev-python/jinja[i18n], py3-capable depends on dev-python/Babel, py3-uncapable | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Michał Górny <mgorny> |
Component: | Current packages | Assignee: | Python Gentoo Team <python> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | skrattaren |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 448026 |
Description
Michał Górny
2012-12-19 19:51:33 UTC
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 |