cryptography version - Githubissues

AzureAD / microsoft-authentication-library-for-python

Microsoft Authentication Library (MSAL) for Python makes it easy to authenticate to Microsoft Entra ID. General docs are available here https://learn.microsoft.com/entra/msal/python/ Stable APIs are documented here https://msal-python.readthedocs.io. Questions can be asked on www.stackoverflow.com with tag "msal" + "python".

https://stackoverflow.com/questions/tagged/azure-ad-msal+python

Other

788 stars 194 forks source link

cryptography version #416

Closed mihaimyh closed 2 years ago

mihaimyh commented 2 years ago

Cryptography changed their versioning strategy, latest being cryptography 35.0.0 which breaks installation for my package since msal requires:

msal [required: >=1.7.0,<2.0.0, installed: 1.10.0]
- cryptography [required: >=0.6,<4, installed: 3.3.1]

https://github.com/pyca/cryptography/issues/6345

rayluo commented 2 years ago

We already released MSAL 1.15.0 five hours ago, which allows the use of cryptography 35.0.0 (and more). You would need to investigate why your environment's correct MSAL dependency declaration ("msal [required: >=1.7.0,<2.0.0, installed: 1.10.0]") does not download MSAL 1.15.0 for you. It is possible that your project uses some other package foo which unnecessarily pins msal==1.10.0 or msal<1.11.0.
On the other hand, even if your environment successfully download MSAL 1.15, your environment would NOT currently download cryptography 35.0.0, because one of MSAL's upstream dependency, PyJWT, does not (yet?) allow cryptography 35.0.0. You would need to either wait, or manually upgrade cryptography.
Out of curiosity, is your project already using some cool new features that is only available in cryptography?

bluca commented 2 years ago

Please remove these pointless and random "upper bounds". They are completely wrong, serve no purpose, and break everything everywhere once a year. They only make sense when there's a specific and known breakage - but then and only then. It is not the case here.

rayluo commented 2 years ago

We had an inconclusive offline discussion with Luca on Cryptography's official deprecation policy which we derive the current <X+3.0.0 upper bound from. As it current stands, MSAL will periodically update its dependency's upper bound when the time comes.

Also, because MSAL itself strictly follows Semantic Versioning, MSAL's consumers will always be able to smoothly upgrade to a higher version of compatible MSAL, so that those rolling upper bound shouldn't be an issue.