Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove Mutagen because file mount combined with Orbstack is fast! #747

Closed
wants to merge 12 commits into from

Conversation

lewisvoncken
Copy link

No description provided.

Disable Mutagen because it slows down the installation and the mount is fast enough on Mac
Disable Mutagen because it slows down the installation and the mount is fast enough on Mac
Disable Mutagen because it slows down the installation and the mount is fast enough on Mac
Disable Mutagen because it slows down the installation and the mount is fast enough on Mac
Disable Mutagen because it slows down the installation and the mount is fast enough on Mac
Disable Mutagen because it slows down the installation and the mount is fast enough on Mac
Disable Mutagen because it slows down the installation and the mount is fast enough on Mac
Disable Mutagen because it slows down the installation and the mount is fast enough on Mac
Disable Mutagen because it slows down the installation and the mount is fast enough on Mac
Disable Mutagen because it slows down the installation and the mount is fast enough on Mac
Disable Mutagen because it slows down the installation and the mount is fast enough on Mac
Update the env-init help section by removing mutagen
@iriks-it
Copy link

iriks-it commented Feb 7, 2024

👍🏻

@bap14
Copy link
Member

bap14 commented Feb 7, 2024

@lewisvoncken This is the wrong approach to take. Warden is not locked to OrbStack as the underlying container platform. It's only locked to docker and docker compose, be that Docker Desktop, OrbStack, Containerd, Lima, Colima, etc.

I believe the proper way to handle this is to make Mutagen an optional service that can be turned on or off per environment, and potentially globally, using the .env file like we can do with ElasticSearch, Varnish or Blackfire. This way we're still backwards compatible with all of the existing Warden releases while allowing those using different Docker platforms to choose to use bind mounts or Mutagen.

Cc. @navarr

@navarr
Copy link
Member

navarr commented Feb 13, 2024

I have to agree with Brett, this is definitely the wrong approach. I wouldn't mind it being optional, but removing it entirely is a non-starter.

@joseluisi4
Copy link

@bap14, In my experience, Mutagen is no longer necessary in Docker Desktop, in fact, it is counterproductive, I have been using Warden without Mutagen on my Mac m2 for several months and it works much better, I no longer have file desynchronization problems and a notable decrease in memory consumption.
Since Docker Desktop made VirtioFS as the default file sharing implementation, Mutagen is not needed.

On the other hand, I think that the .env file is not the best place to add the Mutagen configuration since this is a preference of your machine and not of the project.

@bap14
Copy link
Member

bap14 commented Feb 14, 2024

@joseluisi4 I'm not against deprecating Mutagen; however, we have to keep legacy projects and environments in mind. VirtioFS is still not the default in Docker Desktop and so may not be enabled in every environment. If we go down this path, which I'm not against, we should mark it as deprecated in the next release and target the next, or one after next, minor release.

So for example the current release is 0.14.2. In 0.14.3 we implement the ability to disable Mutagen via the .env config. We'll also need to add a notice every time Mutagen sync starts via the warden env up command to inform that Mutagen is being deprecated. The default is still to use Mutagen. In 0.15 we can swap the default of using Mutagen to default to off while still having the ability to enable it if wanted.

@joseluisi4
Copy link

@bap14, I have created a PR with the changes you suggest: #749

@navarr
Copy link
Member

navarr commented Feb 22, 2024

Closing this as work proceeds in the replacement PR.

@navarr navarr closed this Feb 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants