It only depends on Finder for a very specific use case: Registering commands. Many applications using the HttpKernel standalone don't need this feature. That's why it's in the suggests section instead (it isn't required for basic usage).

Furthmore, I would not advise you to use any bundle outside of the framework.

Btw, this issue will probably be fixed by #9406

@wouterj, I agree that registering commands is a very specific use case for HttpKernel, but on the other hand, I don't expect fatal errors from composer-managed package, when suggested dependency is not installed.

After some deeper investigation looks like it is FrameworkBundle who needs hard dependency on Finder, since FrameworkBundle is using commands registration, provided by abstract class in HttpKernel.

Furthmore, I would not advise you to use any bundle outside of the framework.

IMO, this suggestion defeats the purpose of splitting symfony into components, bridges and bundles.

@RomanShumkov : agreed about the suggsted dependency problem, but i disagree about the splitting comment.

Bundles are generally framework specific by definition (not the case with WebProfiler). The components and bridges are split out to be reused.

I agree that registering commands is a very specific use case for HttpKernel, but on the other hand, I don't expect fatal errors from composer-managed package, when suggested dependency is not installed.

I agree that there are some things that should be improved. I propose:

• Make sure there is no fatal error when a suggested package is not installed. Instead, throw a custom exception with a better description.
• Add explaination to the suggest section to explain when the suggested packages are required

IMO, this suggestion defeats the purpose of splitting symfony into components, bridges and bundles.

No, exactly the oposite: It is a result of this great decoupling. Due to this decoupling, components and bridges are designed to work standalone. It's the bundles which are designed to integrate this standalone libraries into the Symfony Framework. Without this decoupling, everything would have been coupled to the framework. Now, just the bundles are.

Not sure if we have the same understanding of what framework is :)

For me it's symfony/symfony package and that's why I was surprised by advice of not using bundles outside of the framework . Having dependency on entire symfony/symfony package looks like overkill, when creating/using simple bundle, e.g. for exposing existing non-sf2 application services over the web or command line interface.

In theory, bundle is just a plugin/extension point for handling requests using kernel, so having dependency on HttpKernel or FrameworkBundle should be enough, when things like persistence, logging, security etc, are already implemented outside of the bundle (possibly in non-sf2 way).

If however suggestion was about depending on FrameworkBundle, just ignore my previous comment.

Make sure there is no fatal error when a suggested package is not installed. Instead, throw a custom exception with a better description.
Add explanation to the suggest section to explain when the suggested packages are required.

@wouterj, +1
Also would be great to know supported versions of Finder component from suggestion and/or exception message.
Having Finder as a required dependency of FrameworkBundle would be even better, since console applications based on FrameworkBundle are using Finder for finding console commands within bundles.

It is very common for a package to "fatal error" when you use a feature that require you to load a suggested package (not symfony specific at all). Having a nice error message is a nice to have but it can't be enforced and require great case by case care and it will certainly be hard if not impossible to enforce these errors everywhere they could be usefull on the long run.
I'm thus closing. Feel free to open PRs if you spot good "missing dep" reporting candidate points.