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
Consider unlocking cryptography requirement in setup.py #467
Comments
Looking at the code I don't even see the cryptography package being used. Am I missing something in the code? It seems like cryptography shouldn't even be a requirement. There's:
But that is coming from PyJWT. And that package handles it's own requirements via https://github.com/jpadilla/pyjwt/blob/master/setup.cfg#L42. Thus installing it with the crypto option would pull in It seems like flask-jwt-extended would only inherit this. Even if it's explicitly set then it seems like it would match the requirement that it's duplicating from PyJWT rather than requiring a newer version than what's actually needed. |
That in an I'm not opposed to changing the lower band for crypto though. I'll move it to |
Thanks @vimalloc that would be helpful. I understand with the extras requirement in PyJWT it's a harder requirement to manage. |
I added a comment in #452 but figured it's better to open a new discussion.
Is there a reason (compatibility wise) to lock the version bounds for cryptography requirement? If flask-jwt-extended works with older versions of cryptography it would be ideal to support that option. Unnecessarily locking requirement bounds makes it difficult to package downstream where a given distribution might have an older version of cryptography.
Having the version locked like this conveys that you "need" cryptography>={some_version} for flask-jwt-extended to work but based on the commit history it doesn't seem like this is actually the case.
In reference to https://github.com/vimalloc/flask-jwt-extended/blob/master/setup.py#L33
The text was updated successfully, but these errors were encountered: