Retain ability to use the old requests_kerberos where request_gssapi is not available yet.
Fixes #882
rebased onto d5b53fc126f156437633a0d5b3ea6b5fa4143c0a
@tkopecek thanks for the help, CI passes now! (following up from #2274)
Thank you for writing this patch!
I'm confused why we don't simply import requests_gssapi without renaming it to the obscure reqgssapi name.
import requests_gssapi
reqgssapi
This would allow us to set requests_kerberos = None, and this would make it easier to read and understand that hairy code below that tests requests_kerberos.__version__ for the principal kwarg support. Like "If we have requests_gssapi, assume that the principal kwarg will always work without checking __version__"
requests_kerberos = None
requests_kerberos.__version__
principal
__version__
I just didn't want to have divergence at this stage, once we remove the support for requests-kerberos and the even older krbV cleanup can be done.
I see there were some comments in #2274 about the lack of python-requests-gssapi on el6 and el7. As a Fedora packager, is that something I can help with, or are those platforms too old for the latest versions of python-gssapi + python-requests-gssapi? It would simplify QE if we could reduce the options.
I do not know about EL7, but almost certainly EL6 can't do python-gssapi/request-gssapi easily enough, we just need to wait for EL6 to die a graceful death ...
python-requests-gssapi is packaged for epel7.
el6 doesn't support new enough python tooling (cython, etc.) for python-gssapi. Heck, I have to patch around cython bugs just to build in el7, even.
Better would be to stop caring about el6, given even el7 is in maintenance mode.
any obstacle to merging this one ?
Capacity :- ) We need to test it more - I've scheduled if to 1.23 already but if there is some strong reason to squeeze it into 1.22 we can discuss it.
When is 1.23 going to land in Fedora ? I am providing patches like this because we want to drop python-kerberos from Fedora, ans we'll never do it if we can't make a concerted effort to remove all dependencies and then ban re-entry :-)
It would be around October. But yes, it make sense to squeeze it into 1.22
the version check doesn't seem necessary anymore. requests-gssapi's first GA is 1.0.0
@julian8628 as mentioned before that code runs with both requests-gssapi AND requests-kerberos, for gssapi it is redundant but it is still needed if request-kerberos is the only available.
Metadata Update from @tkopecek: - Pull-request tagged with: testing-ready
breaking automerge, removing testing-ready temporarily
Metadata Update from @tkopecek: - Pull-request untagged with: testing-ready
Is there anything I need to do here ?
We need to merge all other testing-ready PRs first, so it is rebasing correctly. No need for action.
there's no python2-requests-gssapi on fedora32+ (python-requests-gssapi is python3-requests-gssapithere, and py2 ver is available on fedora29 and 28) I think we could just remove this part for python2-koji
python2-requests-gssapi
python-requests-gssapi
python3-requests-gssapi
does this make sense? https://pagure.io/fork/julian8628/koji/commits/pr2280
@julian8628 sounds reasonable ...
Do you want me to amend this PR with that commit ?
@simo Yes please. Appreciated that!
rebased onto 3b9fcc664f8e1da3eadf27a54555eeae503687c3
Done
Metadata Update from @jcupova: - Pull-request tagged with: testing-done
Commit 18e0e880 fixes this pull-request
Pull-Request has been merged by mikem
resolved minor merge conflicts with #2244
Are you sure the change in util/kojira is correct ? It seem to undo something I was not touching in my original commit
to be clear I think gssapi_login _> krb_login is wrong in your conflict resolution
Retain ability to use the old requests_kerberos where request_gssapi is
not available yet.