I'm experimenting with some changes:

https://pagure.io/fork/pavlix/koji/branch/python3

So far I couldn't get koji running but the changes seem to be mostly good.

There is partial work here:
https://github.com/mikem23/koji-playground/commits/py3

I believe @ralph may have done some work on this as well.

It is a thorny problem, and we'll have to figure out what we're going to do for RHEL5 (probably fork).

I didn't get very far -- I stumbled on the SSL implementation.

@mikem @ralph I didn't expect so quick answers. I didn't check this ticket for a while and worked with my own changes. I got it working (to the extent that koji moshimoshi succeeds) and I created a pull request. I guess it still needs some improvement.

https://pagure.io/koji/pull-request/152

This is needed for us to port Bodhi to Python 3 as well.

@bowlofeggs Let me know if I, as the author of py3 patches for all sorts of tools including koji (see pull request), can be of any help. The problem with koji is that they insist on compatibility with Python 2.4.3 which is not kept in my patches using 2.6/3.x syntax and the six library.

@pavlix @bowlofeggs @mikem @mikeb Now that Koji 1.11 has been released, could we drop the compatibility with Python older than 2.6? The next release of Koji is likely to be quite far out (given how long this one took), so we might as well take the opportunity to move forward.

The Python 2.4 restriction is quite stifling, and IMO, inappropriate given that a koji client script could be carved out and maintained for EL5 if we really wanted to continue caring about it. Koji servers should not be running on EL5 anymore.

@ngompa Let's not assume the next Koji release will be so far out. I'm really happy with the increased pace of improvement, thanks to all of you who have been submitting PRs! Now that Koji is getting more attention, I think we can target more frequent releases going forward.

I agree that the Python 2.4 restriction is a problem. The hub is not the issue, it's the builders. We're in the process of retiring some old RHEL-5 builders, and once that's done I think we can safely drop Python 2.4 support.

@mikeb I don't see why the existence of RHEL 5 builders (that are in the process of being discarded/upgraded anyway) should allow Koji to be held back. Absolute worst-case scenario: we'll just get Koji's dependencies working against the EPEL 5 python26 package. That is still possible.

And just to emphasize this point very directly: Koji is now the single largest blocker to having Fedora Infrastructure successfully migrate to Python 3. Because of Koji, Koschei, Bodhi, pyrpkg, fedpkg, etc. cannot even contemplate moving to Python 3. There are very strong efforts in the Fedora community to try to get our tooling to Python 3, but Koji keeps that door firmly shut.

Until that particular direction changes, we're stuck. And that's terrible.

@ngompa I was really surprised to find that situation. So please let me know when it makes sense that I rebase the python3 branch (see pull request above) over all those new and ugly changes in koji code base. :)

@mikeb @mikem Why not go ahead and put the current master into a branch (call it koji-1 or something), and go ahead and start treating master as koji-2 so that we can quickly start dropping these constraints now? Then @pavlix, myself, and others interested in pulling Fedora into the future can start working on it, without being held back by RHEL5 and other terribleness.

Hi all and especially @ngompa and @mikem. I have successfully rebased my Python 3.x branch to the current git master that supposedly includes support for requests-kerberos python library. Let me describe the current status. I'm only testing with moshimoshi subcommand so the testing is not thorough yet. There is also the possibility that GSSAPI requires different configuration.

1) Python 2.x with python-krbV works and thus there's no obvious regression.

2) Python 2.x with requests-kerberos doesn't work and therefore I started issue #288.

3) As koji doesn't work with requests-kerberos and python-krbV is not ready for Python 3.x, there's currently no way I could test koji with Python 3.x against Fedora infrastructure.

I have a great update for you. With the workaround mentioned in #288, the latest update of the python3 branch successfully authenticates via Kerberos!

https://pagure.io/koji/pull-request/152

Please lift the Python 2.4.3 compatibility requirement and let's support Python 3.x along with Python 2.6/2.7! I know this is just the client and that there will be issues, but let's at least make the first step and start merging.

Please leverage the Python 2.4.3 compatibility requirement and let's support Python 3.x along with Python 2.6/2.7! I know this is just the client and that there will be issues, but let's at least make the first step and start merging.

You mean we should let go for the Python 2.4.3 support. And I agree! @mikem, can we please drop it now? RHEL/CentOS 5 will surely EOL before another Koji release, and the current version should still be able to communicate with Koji servers of older/newer versions.

You mean we should let go

Yep, I meant lift, don't know what happened in my head, fixed now. I don't see you on IRC, by the way.

It looks like we're stuck once again. I am going to be available at devconf Brno but I don't think I have energy and time to push for this change. I'm writing it just in case someone's coming as well who would be able to make a change.

Commit a871195 relates to this ticket

I updated the pull request https://pagure.io/koji/pull-request/152 on top of the partial changes now included in the tree. I didn't test it as I have no input about actual plan to merge it.

Commit 4833396 relates to this ticket

Here is the proposal for 2.4 compatible (and little-bit ugly) solution #374

/cc @cqi

Very interesting.

Is this issue just about porting the CLI, or does it encompass porting the xmlrpc client as well?

Is this issue just about porting the CLI, or does it encompass porting the xmlrpc client as well?

xmlrpc is central to Koji. All clients use it. There is no way to write a client without it.

Here are details about which parts of the koji code are being used by some consumers of the client side code:

Pungi

• koji.get_profile_module() is used and then config and pathinfo attributes accessed on the returned object
• koji.ClientSession() is instantiated and used
• the cli is spawned as a subprocess

Rpkg

• catches koji.ssl.SSLCommon.SSL.Error and koji.krbV.Krb5Error (from ssl_login and krb_login respectively)
• calls koji.get_rpm_header() and koji.genMockConfig()
• there is also a reimplementation of task watcher that uses koji.TASK_STATES, koji.GenericError and koji.taskLabel – this code should probably be replaced by just calling koji watch-task as a subprocess

Rhpkg

• calls koji.util.parse_maven_param(), koji.util.maven_opts() and koji.util.parse_maven_chain()

I'm dropping #374
Instead created branch https://pagure.io/fork/tkopecek/koji/branch/python3-cli2
I'm doing as much changes are possible over whole codebase. Reason is to be able to run as many unit tests as possible, so we don't need to check/run tests only for cli. And it is even the case for kojid/kojiweb which don't have all dependencies available in python3.

Goal of branch is to have all tests under python2 passing and as much as possible under python3 with cli/lib part passing completely.

@mikem are you ok with it (primary issues with rest are unicode/bytes/str), or should I isolate cli + lib for PR/1.13?

PR #417

PR #417 which fixes this issue was merged.