Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mutagen – Cloud-based development using your local tools

mutagen.io

Post reply on HN
Print view View original

41–50 of 58 posts

Re: Mutagen – Cloud-based development using your local tools

#41

Post by xenoscopic »

vorpalhex wrote: post #39
xenoscopic wrote: post #5

Author of Mutagen here, happy to answer any questions you might have, whether it's about its use with Docker, SSH, its historical integration into Docker Desktop, or its related Mutagen Compose[0][1] project. [0]: https://github.com/mutagen-io/mutagen-compose [1]: https://mutagen.io/documentation/orchestration/compose

Thank you for building this - it appears to solve a real problem that has been a pain in my butt for a couple of years. What are the plans for funding the project? It looks like everything is OSS now, will there be any closed source elements in the future?

To be totally transparent: funding is a bit of an open question, although there's no risk of Mutagen disappearing in the short term.

Mutagen was actually part of YC's S19 batch, and it still has a significant amount of runway from that, but also some revenue from contracting work.

I really want to keep as much of Mutagen as FOSS as possible, ideally MIT licensed. I did just add a small portion of code under the SSPL, which I might experiment with dual licensing to SaaS embedders of Mutagen (since it's really only useful in cases where Mutagen is being embedded in other tooling), but even that I wanted to keep open source for other FOSS projects embedding Mutagen.

In the near term, I have some ideas about plugins and tooling that I want to build on top of Mutagen that will probably be closed source, but those will be separate entities from Mutagen itself and the aim will be to avoid compromising on any functionality that belongs in the core of Mutagen.

Re: Mutagen – Cloud-based development using your local tools

#42

Post by eysi »

gavinray wrote: post #35
eysi wrote: post #23

We use Mutagen for Garden's hot reloading mechanism. (Garden is a dev tool for K8s and hot reloading enables users to sync changes directly to a prod like dev environment as opposed to doing a rebuild and re-deploy). It really is a fantastic piece of technology and completely transformed the whole experience (we were using good 'ol rsync before). In particular it works seamlessly across platforms. If anyone's interes…

This is a MASSIVE endorsement as far as I am concerned I used Garden in the rsync days and it was already pretty good. The code behind Garden is some of the best TypeScript + Node I've ever seen, so if this was better and more performant than what you already had I'm sold. Tell Jon I said hi =)

Thank you say much for the kind words Gavin :)

Re: Mutagen – Cloud-based development using your local tools

#43

Post by xenoscopic »

inportb wrote: post #32

Looks like it handles two-way sync very well, but could it keep more than two participants in sync? I'm sort of "abusing" Syncthing to sync Docker volumes (mostly just configuration and helper scripts) across several hosts. It works well, and the only things I'm missing are file ownership preservation and low-latency "instant"-feeling sync. csync2 gets it right, but it's fragile and needs a lot of babysitting. I'm wo…

One way you can do this with Mutagen is to use a hub-and-spoke topology, where one copy of the files (say the one on the laptop where you're coding) is the "hub," and then you have multiple two-way (or one-way) synchronization sessions going out to the various "spoke" endpoints. In the two-way case, changes on a spoke endpoint will be propagated out to the other endpoints by first propagating to the hub. Obviously, you can have contention in this case if you have ultra-high-frequency updates to the same sets of of files, though the conflicting operations would have to occur on a smaller timescale than that of a single Mutagen synchronization cycle (which is typically somewhere around 100ms for an average codebase). Also, in the case of contention, Mutagen will simply display the conflicting files to you and you can delete the "losing" copy. You can also set auto-resolution behavior with Mutagen's `two-way-resolved` mode to let the hub win in conflicts, or use `one-way-replica` mode to make all the spoke endpoints replicas of the hub, or some combination of all these things, etc.

Re: Mutagen – Cloud-based development using your local tools

#44

Post by zmmmmm »

Looks like a really handy tool and essentially the logical endpoint of all the various hacky manual file watcher / scripted copy type sync things we end up doing to work across environments if they were developed into a full solution.

We work quite hard to maintain unified production/dev config for our docker-compose setups. Mutagen looks like it could simplify some of these since a whole layer of complexity comes from trying to optionally map ports and volumes in such a way that it works for development, while not being inappropriate in test/production. If instead, mutagen can virtually connect / synchronize these it'll be a lot simpler.

I do wonder a bit how debugging works .... if something is running in a container, it's great I can hot sync my code there, but what happens when I put a breakpoint in the code in my IDE?

Re: Mutagen – Cloud-based development using your local tools

#47

Post by dutchbrit »

karlshea wrote: post #13

I've been testing Mutagen's file sync through DDEV on a Drupal project and it's pretty nice! The project is way more snappy than using NFS mounts on the Mac (which was already WAY faster than bind mounts), and DDEV has file ignores set up correctly so the project's media files aren't synced and disk usage isn't doubled.

Same here - works wonders when developing Magento projects

Re: Mutagen – Cloud-based development using your local tools

#48

Post by jeffnappi »

osener wrote: post #46

Mutagen and mutagen-compose + an EC2 instance work great as a replacement for Docker for Mac. This setup you to develop and run Intel images without performance penalty. Both on M1 and on Intel I’m never going back to Docker for Mac again if I help it.

An important thing to note is that the _worst_ part about Docker for Mac is the lousy disk IO performance for shared drives. This can be almost fully mitigated by using NFS mounts instead[0].

In general Docker for Mac is far from ideal - particularly considering you must allocate a set block of memory to the VM. If only it was the year of the Linux Desktop :grin:

[0] https://gist.github.com/vschoener/b0b5ae08625744a1f4ad414027...

Re: Mutagen – Cloud-based development using your local tools

#50

Post by kyriakos »

bliteben wrote: post #49
kyriakos wrote: post #3

using mutagen as a workaround for the Windows WSL I/O slowness. great and rock solid tool.

its not that bad if you use the native filesystem, although then you have to actually get your files into the native filesystem

Using IDE in Windows and execution in wsl2. So IDE has files on Windows file system and use mutagen to keep them in sync with wsl2 file system via ssh. It's actually instant, only downside is duplication but thats a small price to pay.
Post reply on HN