Closed dlqqq closed 1 year ago
cc @kevin-bates @davidbrochart
Base: 81.43% // Head: 83.24% // Increases project coverage by +1.80%
:tada:
Coverage data is based on head (
6207f57
) compared to base (71c90c6
). Patch coverage: 100.00% of modified lines in pull request are covered.
:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
Per discussion with Jupyter server team, it is the consensus that LocalFileIdManager is not yet ready for mainstream use.
I'm not sure this is quite correct. I recall expressing a concern that being so closely tied to the filesystem was going to be problematic due to the wide variety of filesystems. And there seemed to be some consensus that using a mechanism like watchdog
or watchfiles
might be more useful since they know filesystems (or at least filesystem idiosyncracies would be "their problem"). But I don't recall a consensus that LocalFileIdManager
was not ready for mainstream use - heck, it's still in its infancy.
That said, it does sound like RTC's usage is increasing, and a release is looming, so I think having a fallback in the ArbitraryFileIdManager
may be a good idea.
@kevin-bates That was the impression I got from @ellisonbg. @ellisonbg Could you offer your thoughts on this?
Per discussion with Jupyter server team, it is the consensus that LocalFileIdManager is not yet ready for mainstream use. Hence we are setting the default file ID manager to be ArbitraryFileIdManager regardless of the current contents manager.