What's needed?
We need to have more flexibility to configure a FileWatcher. At the moment all watching is recursive and there is no way to set own filter and other options that are very useful to have.
Proposed solution
I see mainly 2 options that we might need to explore in more depth:
1. Making FileWatcher just a glue to use awatch with channels
This means, we just take a awatch instance in the FileWatcher configuration and we also use awatch's own event types, etc. This allows for full flexibility and zero(ish) maintenance cost for updating to new versions of awatch that could provide even more options.
The downside is stopping can't be taken care of by the FileWatcher, the users will have to provide an event themselves to stop, if they need to stop the receiver. Or maybe we can just use Task.cancel() to stop it.
2. Making FileWatcher expose more awatch options in the __init__
This means that we take in the __init__ an option to pass watch_filter, debounce, recursive and other options that will be just forwarded to awatch.
The downside is we always need to update if awatch if more features are added, and we need to create/maintain wrappers for other awatch types if we want to make the implementation hidden.
Since we are coupling FileWatcher with awatch anyways, and using a file watcher is not something that needs to be done very often (it is still a lowish-level construct) and has many things to consider, I lean more towards using the first approach.
Use cases
The main use case for now is the ConfigManagingActor in the SDK.
With the current FileWatcher implementation, the config manager needs to watch for a whole directory recursively just to watch for one individual file, and do the filtering manually, which is not ideal (and was difficult to understand what was going on).
Alternatives and workarounds
Use awatch directly or do some of the work manually.
Additional context
We are considering changing the underlying library, so we should have this in mind before addressing this issue:
What's needed?
We need to have more flexibility to configure a
FileWatcher. At the moment all watching is recursive and there is no way to set own filter and other options that are very useful to have.Proposed solution
I see mainly 2 options that we might need to explore in more depth:
1. Making
FileWatcherjust a glue to useawatchwith channelsThis means, we just take a
awatchinstance in theFileWatcherconfiguration and we also useawatch's own event types, etc. This allows for full flexibility and zero(ish) maintenance cost for updating to new versions ofawatchthat could provide even more options.The downside is stopping can't be taken care of by the
FileWatcher, the users will have to provide an event themselves to stop, if they need to stop the receiver. Or maybe we can just useTask.cancel()to stop it.2. Making
FileWatcherexpose moreawatchoptions in the__init__This means that we take in the
__init__an option to passwatch_filter,debounce,recursiveand other options that will be just forwarded toawatch.The downside is we always need to update if
awatchif more features are added, and we need to create/maintain wrappers for otherawatchtypes if we want to make the implementation hidden.Since we are coupling
FileWatcherwithawatchanyways, and using a file watcher is not something that needs to be done very often (it is still a lowish-level construct) and has many things to consider, I lean more towards using the first approach.Use cases
The main use case for now is the
ConfigManagingActorin the SDK.With the current
FileWatcherimplementation, the config manager needs to watch for a whole directory recursively just to watch for one individual file, and do the filtering manually, which is not ideal (and was difficult to understand what was going on).Alternatives and workarounds
Use
awatchdirectly or do some of the work manually.Additional context
We are considering changing the underlying library, so we should have this in mind before addressing this issue: