Allow alternative implementations of unison-fsmonitor

[d4rky-pl]

Error/Feature Requestion/Docs

There's an alternative implementation of unison-fsmonitor which uses Facebook watchman and is implemented in Rust and it's insanely faster compared to eugenmayer/dockersync/unox (we're talking <1s vs 2-5s for each update). Unfortunately to use it I had to modify the code of docker-sync to prevent it from forcing me to remove it and installing unox instead.

It would be amazing if we could somehow disable the unox check, either with --flag or even ENV var.

[EugenMayer]

Happy to review an PR for that. I tested watchman and it has other drawbacks - it will by no means be a clean win / one sided

[d4rky-pl]

@EugenMayer what option would you prefer - a flag when starting docker-sync, an ENV var or detecting alternative unison-fsmonitor from homebrew?

Also - what were those other drawbacks, if you can recall them, so I can keep an eye on them?

[d4rky-pl]

@EugenMayer if we're going to go with detecting alternative unison-fsmonitor from homebrew, I can also add a warning that says it detected something other than unox and unox is the recommended solution

[EugenMayer]

is #776 enough to get this running already, is the implementation interface of the alternative just feature complete with the other?

Could you post some benachmarks / ideas / motivation so we can move this into the documentation as an option for people to try / optimize. I'am yet not sure what troubles i had back then, so what downtime watchman had, but things might change and we might need to find, if any, the weakspot and the sweespot.

I would really love to add this to the docs, what do you think?

[d4rky-pl]

The #776 is enough to make this running, the whole instruction to enable it is basically:

brew uninstall eugenmayer/dockersync/unox
brew install autozimu/homebrew-formulas/unison-fsmonitor

and it seems to work as a drop-in replacement. I'm not sure how to run benchmarks on this one since what speeds up the most is unison itself, specifically how long it takes until it gets to the Looking for changes part (and that one does not include any timing information)

Unox

with-unox.mp4

unison-fsmonitor

with-unison-fsmonitor.mp4

The drawback I did notice is that if you modify files too fast the changes sometimes do not get synced until another change gets created (so it's still not ideal for things like npm/yarn install). For us this is acceptable since we're using docker-sync mostly for syncing our own changes only but it merits adding a caveat. (This happens with unox as well)

BTW I only now realized but this alternative implementation is just using Rust fsevents implementation and NOT watchman - it was linking to watchman docs which is why I got confused (and I'm using watchman everywhere because of webpack so I already had it installed) but I double-checked the source code and it's just plain Rust.

[d4rky-pl]

To be more specific, it's not about files getting modified too fast, it's about files modified when unison hits the reconciliation phase. This might also be happening with unox (I would need to run more tests)

This is also happening with unox.

[d4rky-pl]

@EugenMayer I think we can add this to the Getting Started > Advanced / optional section of the docs for now:

.. caution::

    Starting with docker-sync 0.7.0 if you're using unison, you can also install [an alternative](https://github.com/autozimu/unison-fsmonitor) to unox. It seems to be faster and more performant but it has not been fully battle-tested yet.

I can add it to the PR, just give the word :)

[Ewarren7]

@d4rky-pl to clarify, I assume this is mainly beneficial when using this with the sync strategy for a project set to unison? Or is this also beneficial for native_osx strategy that uses unison in the sync container?

[EugenMayer]

@d4rky-pl as you suggested, only for unison strategies, not native-OS X