Retrofit repo class as context-man to cleanup global mman on repo-delete
#555
Conversation
Improve API for problems like gitpython-developers#553.
Apply codereview comments of gitpython-developers#541.
Current coverage is 94.50% (diff: 92.00%)
|
|
@ankostis Do you think I should wait till tomorrow until I cut the release to be able to include this one? Or would you prefer to just have this released separately at a later time? |
|
Sorry @Byron , I've just seen your message. I'm not exactly sure what happened and you could not include my PR in 2.1.1. |
|
Even though the implementation seems to be in place, it would certainly be nice to include an example in the |
|
Apologies for not having the time, Too overloaded to fix the TCs in the next weeks :-( |
|
I think so too :)! Sorry for the incredible delays. |
The gc module was already imported at module scope in git/repo/base.py, since f1a82e4 (gitpython-developers#555). Importing the top-level git module or any submodule of it runs that import statement. Because the gc module is already imported, reimporting it is fast. Imports that there is no specific reason to do locally should be at module scope. Having them local decreased readability, in part because of how black inserts a black line between them and gc.collect() calls they are imported to allow. An alternative to this change would be to remove the preexisting top-level "import gc" (there is also another one in the test suite) and replace it with a local import as well. I am unsure if that would affect performance and, if so, whether the effect would be good or bad, since the small delay of the import might potentially be less desirable to an applicaion if it occurs while the work of the application is already in progress. If a gc.collect() call runs as a consequence of a finally block or __del__ method being called during interpreter shutdown, then in (very) rare cases the variable may have been set to None. But this does not appear to have been the intent behind making the imports local. More importantly, a local import should not be expected to succeed, or the imported module usable, in such a situation.
Some changes for this release:
See #553 for difficulties when working on Windows, where open file-handles actually "lock" the underlying files, and repos cannot be deleted.
More changes:
cmd._call_process().gitpython.util.rmtree()for deleting repos in Windows where blobs are readonly.