4 ms·
This sounds useful. But one question that comes to mind right away: Does Mutagen handle the case where “local tools” (running on a completely different archite
by eddyg 4y ago
This sounds useful. But one question that comes to mind right away:
Does Mutagen handle the case where “local tools” (running on a completely different architecture than the remote) still need to “know” about include/header/library/etc. files from the remote machine in order to provide working “intelligence” capabilities?
It’s one thing to efficiently sync “code”, but it’s another to make local tools fully-aware of the remote system’s header files, libraries, etc.
- xenoscopic 4y agoOn the synchronization front, Mutagen's only goal is to facilitate the synchronization of files (albeit with a focus on development-related settings and low-latency for a "real time" feel). It doesn't attempt to integrate with any higher-level tooling (except in the cases of Docker Desktop and Compose, which is facilitated via external projects). That sort of tooling, language, and framework-specific integration is a bit outside the project's target scope (and something that becomes very domain-specific). Mutagen will, however, happily operate between different operating systems and architectures, so things like working with a remote amd64-based Docker engine from your local arm64-based laptop are totally possible. Also, several external projects (such as DDEV[0] and Garden[1]) do use Mutagen as a low-level component in their stack to provide synchronization that does "know" a bit more about the framework that you're using. [0]: https://ddev.com/ https://ddev.com/ [1]: https://garden.io/ https://garden.io/
- eddyg 4y agoJust wanted to say thanks for taking the time to reply, and for the links to those other projects that use Mutagen!