Hi Piotr, > Upstream switched to Python 3.X and I don't want to port it back to 2.X. > I can provide an older version of python-aeidon package (in a separate > source package) as a temporary solution, but I'd rather not release it > with Jessie.
Ah. That's unfortunate. That's a pretty big break in compatibility. Thanks for your analysis of how ttkit could be ported to python 3. Unfortunately, there are at least two fairly major reverse-dependencies from the same upstream developers that will make this very difficult: pootle¹ and virtaal. Both of these are python 2-only and import translate. They have dependencies on things like python-django and python-gtk2². (And yes, perhaps we should split the translate-toolkit package into python-translate and translate-toolkit packages where the latter only ships the files in /usr/bin and their manpages so that it is more obvious that there is both a module API and a command line interface to translate-toolkit. It's not obvious to me whether it's worth doing that split for the sake of a few small files in /usr/bin.) I'll forward your analysis of this porting effort upstream, but I suspect that pootle and virtaal will prevent any porting of ttkit to python 3 for the time being; disabling subtitle support might be our only solution. I suspect (but have not checked) that the conversion to python 3 will also require some significant reworking of the translate-toolkit API to change what parts are done in bytes and what parts are in unicode/strings. ttkit is one of those places where python 3 will make the code much more robust and easier to work with but the conversion will be challenging. cheers Stuart ¹ I have now been trying to get pootle back into Debian for almost two years but I can never find a time where all its dependencies are actually in unstable and with compatible versions ☹. At present, it needs a newer python-django-south and an older python-django than what is available in sid. I'm starting to come to the conclusion that either pootle is very very unlucky or maintaining large python programs is impossible unless you minimise your exposure to modules that are outside your control and NIH as much as possible. Sadly, I think upstream is close to giving up on working with distributions and will encourage everyone to use virtualenv instead. If only API compatibility were more of a priority in python-land. ² I assume python-gtk2 is going to be a problem in itself some time soon. -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint BE65 FD1E F4EA 08F3 23D4 3C6D 9FE8 B8CD 71C5 D1A8 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/kqpdtf$ega$1...@ger.gmane.org