Did you check the work in https://pagure.io/pagure/commits/py3_work2 ? I would be better to go from there I think.

I did, in fact I pulled commits out of it in this branch here, adding more fixes and docker-compose config here

since we're using six already I think I'd have used:

from six.moves import input as raw_input

This was explicitly unicode and now no longer is?

Isn't this used somewhere?

Let's remove those, the only ones I keep are the ones for the patch (which should be commented out by default, I just uncomment them when I need)

No, luckily, it isn't, as this code makes no sense in py 3

It would always be unicode in py3 (as all strings are unicode in py3). For py2 it would be safer to convert it explicitly

Okay, I'll keep those for now (might be useful until all testcases are fixed) - and remove in the final version

Current status: SKIP=2, errors=2, failures=15

I think I knocked out all the obvious failures

A short summary on failing tests:

• ./runtests3.sh -vv tests/test_pagure_lib_git.py:
  random fails across any tests, which use test_update_git
  Seems to happen on master as well

• ./runtests3.sh -vv tests/test_pagure_lib_git_diff_pr.py:
  wrong number of commits in PR?
  Happens on master

• ./runtests3.sh -vv tests/test_pagure_flask_ui_repo.py:PagureFlaskRepotests.test_compare_commits:
  looks similar, shows 2 commits when 3 are being diffed
  Happens on master

• ./runtests3.sh -vv tests/test_pagure_flask_ui_issues.py:PagureFlaskIssuestests.test_view_issue_raw_file:
  404 when an image is being accessed
  Happens on master

• ./runtests3.sh -vv tests/test_pagure_lib_notify.py:PagureLibNotifytests.test_send_email:
  email address is being incorrectly encoded
  Crashes in a different place on master

• ./runtests3.sh -vv tests/test_pagure_flask.py:PagureGetRemoteRepoPath.test_is_repo_committer_logged_out:
  fails with 'RuntimeError: Working outside of application context.' - not sure why this test
  in particular - and how do I fix it. Not reproducible on master

str(err)

what's the point if we use six? six.u(...) is your friend

2017

don't really like this

return six.next(walker)

why not to use universal_newlines for subprocess?

I got tired of scrolling this massive thing ;)

So some advises:
- Use six.next() for iterators instead of playing around .next() vs .__next__()
- Use six.u() when you need to get unicode

Fixed this one and other occurrences of 2016

This test still fails btw, same as in py2 version - 'To' is not being decoded properly. I'll give it another look soon

Good idea, fixed

Fixed, thanks

Fixed

Not sure how that'd be useful - the problem is to have it converted to unicode.

Note, there is a code piece to have those kept below: if not keependsetc. This part should be rewritten, but I doubt this PR is a good place for this

Now that #3114 has been merged pagure should be python3 compatible :)

Thanks for your work on this, it was useful to us :)