Implemented new mutagen session which will sync "/var/www/.composer/"…

[u-maxx]

Implemented new mutagen session which will sync "/var/www/.composer/" folder to local "~/.composer" folder when bin/composer command executed. Main purpose is to stop syncing the composer folder via Docker's :delegated config in docker-compose.yml

[davidalger]

@u-maxx I'm curious what the technical reasons behind moving this to using a mutagen sync. I haven't run into anything which would indicate it's needed for performance, but if others have I would love to know. From my perspective the fewer mutagen sync sessions we have the better as it will keep things simpler.

[u-maxx]

@davidalger please note that it has no-watch for both alpha and beta so it should not cause anything bad. In general, I do not want to keep any default Docker sync (even :delegated) since it was not working fine with other folders... I have tried to replicate the same behavior via mutagen, as it was done via :delegated, but additionally decreasing the number of syncs only to 1, when bin/composer executed

[davidalger]

I do not want to keep any default Docker sync (even :delegated) since it was not working fine with other folders

The primary issue with Docker synced directories is two-fold: consistently and latency. Essentially being a cache directory, consistency of writes doesn't really matter, and neither does latency since these files are disconnected from php requests.

it has no-watch for both alpha and beta so it should not cause anything bad

This is actually why it causes something bad; let me explain 🙂 Doing this defeats one of the primary purposes (in my mind) of having this delegated and/or synced in any manner: the composer cache directory now starts cold every time a new container is launched vs starting hot with what is already on the host machine.

With these changes, this is what is inside the container immediately following start:

 $ bin/bash 
app@2877703427be:~/html$ tree /var/www/.composer/
/var/www/.composer/
`-- cache
    |-- files
    `-- repo
        |-- https---repo.magento.com
        `-- https---repo.packagist.org

5 directories, 0 files

Compare that with using the simple delegated bind mount where the container starts hot with the contents of the composer cache from the host machine:

app@397dce21002c:~/html$ tree /var/www/.composer/
/var/www/.composer/
|-- auth.json
|-- cache
|   |-- files
|   |   |-- aheadworks
|   |   |   `-- module-onestepcheckout
|   |   |       `-- 68f18b4f76567dd8f7599eb50579390f8670df4f.zip
|   |   |-- allure-framework
|   |   |   |-- allure-codeception
|   |   |   |   `-- fb0ecc52f1ad2b58f3c7a0faa31a7bf2367df084.zip
|   |   |   |-- allure-php-api
|   |   |   |   `-- 54a6027e235778cc8249774db13b6bc2541eb8d5.zip
|   |   |   `-- allure-phpunit
|   |   |       `-- af950d8c9f78fa807a755c3e05af4005d12b403e.zip
|   |   |-- amasty
|   |   |   |-- groupcat
|   |   |   |   `-- 0a03e8cd2d7d5eb5a2140cce6e15468d5a3ede9e.zip
|   |   |   |-- module-banners-lite
|   |   |   |   `-- a4de56eb4197d3313f2271d1ae7323594785f2fa.zip
|   |   |   `-- module-special-promo
|   |   |       `-- 4488b579fb6220440cb2488df72e057ef0d3cb14.zip
....

789 directories, 1544 files

The other side-effect of these changes is that unless a mutagen flush is run the packages cached by composer inside the container never make it to the host machine.

My personal take on this is essentially this: Use the right tool for the job. For keeping the entire Magento codebase in sync Mutagen solves a problem, but should not be used where it's not necessary because it does add quite a bit of complexity to the setup and increases the number of

[u-maxx]

Ok, thanks for the detailed description @davidalger, makes sense. I was not using Composer for my m1 projects, so that is why I missed this important part of its features. Would you prefer to just revert my commit? or create the new PR?

[u-maxx]

nevermind, I have just created #50 to revert it

[davidalger]

Thanks @u-maxx

[u-maxx]

Thank you for your help @davidalger !