Exposing watchfiles settings to the user

[cmarqu]

I found that I am getting two Sphinx rebuilds per change saved (with versions of sphinx-autobuild and watchfiles as of today).
Setting WATCHFILES_DEBUG=1, I see

1 change detected: {(<Change.deleted: 3>, 'mytheme.css')}
[Sphinx rebuilds]
1 change detected: {(<Change.added: 1>, 'mytheme.css')}
[Sphinx rebuilds]

It appears to be due to a combination of my editor (Emacs) doing a delete+add for each file save and a slow filesystem (over local network).
I can fix the problem by adding the debounce and step options (https://watchfiles.helpmanual.io/api/watch/#watchfiles.watch) to the watchfiles.awatch call in sphinx_autobuild/server.py and increasing their values:

2 changes detected: {(<Change.deleted: 3>, 'mytheme.css'), (<Change.added: 1>, 'mytheme.css')}
[Sphinx rebuilds]

How could we best expose these settings? Adding extra command line options for such a rare problem might be overkill. Would an environment variable be better?

Coming to think of it, it might even be better to have environment variables for such defaults in watchfiles itself? I'll open an issue there too.

[AA-Turner]

I'm hesitant for the reason you note: this is a seemingly rarely-needed option, and I don't want to commit to supporting more complexity.

Environment variables might be a good option. What are the debounce and step settings you use? Are they reasonable enough to use instead of the defaults?

A

[cmarqu]

I had set them to debounce=300, step=250 without me noticing the additional waiting time between saving and rebuilding. Now I have changed to debounce=200, step=100 and it still works, but the network also has low traffic right now, so it might not be enough for traffic peaks.
I'll keep an eye on it over the work day.
EDIT: I already saw it fail 2 out of 3 times with debounce=200, step=100 now, so it appears to be on the corner.
EDIT2: debounce=300, step=100 seems to work fine.