Try from __future__ import unicode_literals
and possibly absolute_import, division, print_function
too, in our existing Allura .py files. See what sort of issues may arise.
Related email thread starts at http://mail-archives.apache.org/mod_mbox/allura-dev/201504.mbox/%3C553955A5.6020006%40brondsema.net%3E
Closed #771.
ib/7878
Ok, it was worse than I expected :) I've managed to fix some of the issues. A lot of tests still failing, though, and some pages raise unicode errors (e.g. git repo main page) and it need a lot of manual checking.
What I did:
futurize --stage1 --all-imports --unicode-literals -w **/*.py
name
andpolymorphic_identity
to string in all ming models/collectionspackage_data
dictionary keys to string forsetup.py
AntiSpam
decorator. It is quick fix in order to get at least some of the pages to render. We might want to look at it closer and test it more. Don't sure it will work for all the cases. I didn't dig deep in the code to save time to investigate further.The last point was hardest to spot and debug. It is reproducible only if you run wsgi app. If you working locally with
paster serve
this does not arise. AddingLoggingMiddleware
toallura.wsgi
from here helped a lot. It prints request/response environ to apache error log.See also commit comments for some details.
Further work that need to be done:
ForgeHg
and other packages we maintain will probably need steps mentioned above tooMaybe we should tackle these incrementally one by one if we wanna proceed further. They might be intertwined, though.
Last edit: Igor Bondarenko 2015-05-20
Sounds like you made good headway, but as you said, worse than expected. I think some of the fixes (e.g. ming) we might want to try to fix upstream (seems like ming should handle unicode names).
Since there's quite a bit of additional work and testing, with minimal benefit (ready for py3 (which far from anyway) and save some unicode interpolation errors)... I'm ok with letting this sit. Unless someone really wants to make it their personal mission :D
Done in db/7878