[WebProfilerBundle] remove definitions when they are not usable #26115
Conversation
xabbuh
commented
Feb 9, 2018
| 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 |
|
Is anything usable in WebProfilerBundle if you don't have Twig ? I don't think so. |
|
WebProfilerBundle should have a requirement on TwigBundle, not just on Twig. It would solve the issue cleanly in a Flex world when people install things separately. |
|
Probably not, but this at least prevents the |
|
I think the reason to do it this way was to enable usage of the WebProfilerBundle code in Silex without bringing FrameworkBundle. But TwigBundle no longer depend on FrameworkBundle. The only dependency that TwigBundle has and WebProfilerBundle does not have is |
|
@fabpot What do you think? Is it okay for you to add the TwigBundle requirement? |
|
The profiler does not need the bundle, just plain Twig as demonstrated in Silex. I would not add the bundle as a hard requirement. That being said, I can see that with Flex, more and more people have problems with this (even if using Not sure what to do here. |
|
In that case, just removing the invalid definitions as done in this PR should improve DX as clearing the cache afterwards shouldn't fail anymore. |
|
Well, it needs the bundle to have a working twig service (which is what the bundle is doing). Regarding the usage in Silex, TwigBundle does depend on FrameworkBundle anyway, so having it as a dependency would not bring all of symfony anymore (it has the same dependencies than WebProfilerBundle) |
| $container->removeDefinition('web_profiler.controller.exception'); | ||
| $container->removeDefinition('web_profiler.controller.profiler'); | ||
| $container->removeDefinition('web_profiler.controller.router'); | ||
| $container->removeDefinition('web_profiler.debug_toolbar'); |
There was a problem hiding this comment.
Removing all these makes the bundle useless, as the only goal of the bundle is to provide the UI to access the profiler data.
There was a problem hiding this comment.
Sure, but at least clearing the cache does not fail now. I don't care which solution we choose, but anything is better DX-wise than the current behaviour.
|
A way to solve this would be to allow Flex to replace a package by a pack that would be auto-unpacked: This PR looks like a workaround/hack for a missing behavior in Flex. |
|
To be fair, this is not limited to Flex but you would observe the same behaviour when installing the package manually using Composer without Flex. |
but then it's your responsibility to fix your dependencies |
|
So, shall we do this until symfony/flex#360 is implemented? WDYT? |
|
First, WebProfilerBundle never had a dependency on FrameworkBundle, so that's not the reason (and TwigBundle never had a dependency on FrameworkBundle either). But thinking about this one again, I've changed my mind and I think that we can add TwigBundle as a dependency. Let's do it for 4.2 as Silex won't be maintained anymore when it will be released. See #27417 |
…dency (fabpot) This PR was merged into the 4.2-dev branch. Discussion ---------- [WebProfilerBundle] Make Twig bundle an explicit dependency | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #26115 | License | MIT Let's make Twig bundle an explicit dependency of WebProfilerBundle. That's better for DX and as Silex won't be maintained when 4.2 is out, it's the right time to do so. Commits ------- cac37ca [WebProfilerBundle] made Twig bundle an explicit dependency
|
Don't you think that throwing an exception would be better? |