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

[Config] Do not use absolute path when computing the vendor freshness #32579

Merged
merged 1 commit into from Jul 18, 2019

Conversation

lyrixx
Copy link
Member

@lyrixx lyrixx commented Jul 17, 2019

Q A
Branch? 3.4
Bug fix? yes
New feature? no
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets
License MIT
Doc PR

When one uses Docker with a different mounting point between CLI & FPM,
the cache keeps regenerating because the ComposerResource class see a
different path for each SAPI. For example /home/app/app/vendor vs
/var/www/app/vendor.
So if you hit FPM, then the CLI, then FPM, each time a new cache is
generated. So the application is quite slow in dev env. And for people
on MacOSX (with docker) is a big pain! And obvisouly, this never
stabilizes !

This occurs a lot when you have a worker, that crash and reboot in the
background, and you browse the web interface. Or when you have something
that hit your API every X secondes, and you are working on a worker.

When one uses Docker with a different mounting point between CLI & FPM,
the cache keeps regenerating because the ComposerResource class see a
different path for each SAPI. For example `/home/app/app/vendor` vs
`/var/www/app/vendor`.
So if you hit FPM, then the CLI, then FPM, each time a new cache is
generated. So the application is quite slow in dev env. And for people
on MacOSX (with docker) is a big pain! And obvisouly, this never
stabilizes !

This occurs a lot when you have a worker, that crash and reboot in the
background, and you browse the web interface. Or when you have something
that hit your API every X secondes, and you are working on a worker.
@nicolas-grekas nicolas-grekas added this to the 3.4 milestone Jul 17, 2019
@nicolas-grekas
Copy link
Member

Thank you @lyrixx.

@nicolas-grekas nicolas-grekas merged commit 2d2e274 into symfony:3.4 Jul 18, 2019
nicolas-grekas added a commit that referenced this pull request Jul 18, 2019
…r freshness (lyrixx)

This PR was merged into the 3.4 branch.

Discussion
----------

[Config] Do not use absolute path when computing the vendor freshness

| Q             | A
| ------------- | ---
| Branch?       | 3.4
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets |
| License       | MIT
| Doc PR        |

When one uses Docker with a different mounting point between CLI & FPM,
the cache keeps regenerating because the ComposerResource class see a
different path for each SAPI. For example `/home/app/app/vendor` vs
`/var/www/app/vendor`.
So if you hit FPM, then the CLI, then FPM, each time a new cache is
generated. So the application is quite slow in dev env. And for people
on MacOSX (with docker) is a big pain! And obvisouly, this never
stabilizes !

This occurs a lot when you have a worker, that crash and reboot in the
background, and you browse the web interface. Or when you have something
that hit your API every X secondes, and you are working on a worker.

Commits
-------

2d2e274 [Config] Do not use absolute path when computing the vendor freshness
@lyrixx lyrixx deleted the cache-composer branch July 18, 2019 07:06
This was referenced Jul 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants