Mysterious problems since keyring 16.0.1 (somehow caused by traceback kept in global variable) #386
Short story: change introduced in
I have no idea what's exactly going on and which part of the code is really guilty, but the whole problem narrows down to traceback object being kept by keyring/backends/Windows.py in global variable (missing_deps) - most likely traceback keeps frames alive, frames keeps some variables alive etc.
Considering missing_deps is used there only as a boolean (to test whether there were any problems), please consider keeping such a flag instead. Fixes like:
resolve the issue.
(maybe it would be even better to reconsider keeping .traceback inside keyring.errors.ExceptionInfo, this attribute is not used for anything)
PS As I checked, this is the only place in keyring code where ExceptionInfo object is kept for a long time, other places using ExceptionRaisedContext use returned object temporarily.
18.0.1 is going out again here - https://travis-ci.org/jaraco/keyring/builds/510607549
What about 19.0.1 too? From my point of view this is not crucial (mercurial is not yet officially py3-migrated) but this can be faced by people devel-testing py3 version. And of course some non-hg code can also face some similar problem (which, after all, narrowed to spoiling lifecycles and maybe even creating circular refs)