-
Notifications
You must be signed in to change notification settings - Fork 101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Switch requirement to pykerberos #38
Conversation
Previously requirements.txt declared a requirement on kerberos==1.1.1. However, pykerberos is more active upstream. We also remove the version tracking as the current minimum version on pypi is functional. Therefore switching to that, which closes requests#37 Signed-off-by: Dave Walker (Daviey) <email@daviey.com>
I have no particular objection to this, however I think realistically you only tested with pykerberos 1.1.5, so we should pin to that version. |
Personally, I feel that declaring pins purely as a' 'known-good' version is an abuse of requirements.txt. My understanding it is that it should be used to declare known bad compatibilities. This is especially important if pykerberos needed to do a security release, we'd still be pinned to an older version. Ie, <1.1.1 is bad.. or API/ABI breaks on version >=1.1.5... However, just as a QA perspective, it feels like abuse. That said, it is your upstream and not mine... And if you feel strongly about this, i'll change it. :) |
I think what @Lukasa is advocating is a line like: |
Sure, that makes sense.. I was disagreeing that this project should presume If current+1 comes out and it does not work, then adding !1.16 to the However, I appreciate that this is not my project.. And if you feel that
|
That's an interesting position. I think it is worse to break user code unexpectedly than it is to delay our support for new upstream versions. I suspect you disagree. =) |
About pykerberos, there are not much information on pypi about this fork. No maintainer, no source code repository. Looking at the diff, there are:
|
There is also https://pypi.python.org/pypi/python-gssapi/, which looks like much better maintained that the Apple one (or at least more openly) |
If anyone's looking for my input, if pykerberos is a maintained fork of the original kerberos library, then it makes sense for us to switch. As to pinning, if the pykerberos maintainers commit to sever, couldn't we make the requirement >= 1.1.1 and < 2.0.0? |
As to pygssapi, I've used it on another project and was going to work on converting requests-kerberos to use it, but just when I went to do so, the pygssapi project started a conversion from C extension (maybe python) to cffi. When that happened, things broke. If things have settled, I'd be open to a switch. -- this was a while ago, so my memory may be fuzzy on the details. |
I am the current maintainer of pykerberos and intend to fully semver |
That was a typo. I meant semver as in semantic versioning. |
My bad, copying the typo but meaning the same (updated the post) |
I'm currently on vacation, but when I get back and have a chance ill take a look. |
FYI, I just verified in #52 that pykerberos works in the base-case (I haven't tested it with delegation). pypi now includes a link to the issue tracker at https://github.com/02strich/pykerberos, which was updated 4 months ago. |
Addressed by #56 |
Previously requirements.txt declared a requirement on
kerberos==1.1.1. However, pykerberos is more active
upstream. We also remove the version tracking as the
current minimum version on pypi is functional.
Therefore switching to that, which closes #37
Signed-off-by: Dave Walker (Daviey) email@daviey.com