This is only for new projects. Existing projects won't be affected.
No userland code should rely on Sentry-bundle, at least by default.
Even if one needs to, using code from sentry does not require enabling the bundle of course.

I think this is the correct default.

No userland code should rely on Sentry-bundle, at least by default.
Even if one needs to, using code from sentry does not require enabling the bundle of course.

This is a fragile assumption. If I need to enrich the data sent to Sentry, I may need to interact with parts of the bundle, or the bundle could interact with the data in unforeseen ways.

Test may be broken; or worse, get false greens.

That won't happen in any new projects.

Yet, the default right now breaks inspecting test suites that erroneously alter the error handler without restoring it.

Apart from the warning, it shouldn't break tests, we take care of passing through all errors to error handlers below.

Furthermore, that will be solved by getsentry/sentry-symfony#337, but it's a lot of work to be done.

Apart from the warning, it shouldn't break tests, we take care of passing through all errors to error handlers below.

correct, "Apart from the warning", which is not that a minor detail ;)

that will be solved by getsentry/sentry-symfony#337, but it's a lot of work to be done.

it's a lot of work yes! that's why I think we should do this change today, to relax the "pressure" on this issue.

@Jean85 please consider my arguments.

I still see many downsides in this way. Non having the bundle loaded will also not trigger any deprecation coming from the whole Sentry stack, for example.

I'm against this because I personally reversed that approach from inside the bundle due to this getsentry/sentry-symfony#46 (comment) (and following discussion).

Hm..

Indeed this will fix the problem and not affecting exiting users. But it seams like it is a workaround instead of fixing the actual cause. I'll follow getsentry/sentry-symfony#421 and see if we can come up with a better solution.

My two cents: while it's true that this change won't affect existing users, it makes installing the bundle broken for new people because as any other bundle providing services, if my project relies on them it won't work in dev environment until I change the bundles.php explicitly, while I think that the recipe should make it work out-of-the-box (that's what recipes are for, in my opinion). Apart from this, I see this as a workaround rather than a proper solution, and I strongly believe we should instead fix this in the SDK (bundle or core). The preferred solution to me is, as already said multiple times, to rely on Monolog which is the de-facto standard way of logging things in Symfony