Make portalocker optional #117
Conversation
rayluo
force-pushed
the
optional-portalocker
branch
5 times, most recently
from
7ac2952
to
323ac39
Compare
| - python-version: "3.10" | ||
| toxenv: "py310" |
There was a problem hiding this comment.
Python 3.11 is GA. We are planning to support it in next sprint (Azure/azure-cli#24109).
| """It will be raised when unable to obtain a lock""" | ||
|
|
||
|
|
||
| class CrossPlatLock(object): |
There was a problem hiding this comment.
Well, Azure CLI doesn't really need such a complex lock at the comment. Previously ADAL didn't have locking mechanism and worked mostly fine.
There was a problem hiding this comment.
Fair point. But if the current PR's non-portalocker lock is harmless, then we might as well just use it.
We are open to the dummy lock idea, too. We may work on it at a later time. It can be done, but it is more work, in terms of needing to expand the current MSAL EX api to allow a "no lock" option. (The current file-based lock, on the contrary, is a drop-in replacement for portalocker, and keeps the MSAL EX api intact.)
If the file-based lock does not work well for Azure CLI on SAW, we will prioritize the dummy lock work accordingly.
This is currently an experimental PR. It will not be merged, not until we receive some test feedback. To beta test this PR, you will need to pull it from its feature branch.
Usage: There is no API change. MSAL EX will automatically utilize portalocker when portalocker is available in current environment, and switch to a new portalocker-less implementation otherwise.
Note:
portalocker.exceptions.LockExceptionwhich means the locking mechanism is doing its job. After this PR, under the same heavy load, you will seeLockErrorinstead, which also means the new lock mechanism is functioning.CC: @jiasli