Allow configuring behavior via the DOCTRINE_DEPRECATIONS env var

[nicolas-grekas]

In doctrine/DoctrineBundle#1662, we're discussing about how we should best integrate this lib in Symfony, where we'd like the default to be to call trigger_error.

In order to not force autoloading the Deprecations class on every single request just to configure it, I propose to allow configuring the default behavior via the DOCTRINE_DEPRECATIONS env var.

[greg0ire]

Have you considered using a file auto-loaded with autoload.files, that would contain a check followed by appropriate calls to Deprecation::enableWith*? I feel it would result in less complexity.

[stof]

@greg0ire this would still force to load the Deprecations class on all requests even if they never trigger a deprecation.

[derrabus]

I like the idea! This will enable Symfony to ship a very simple recipe for integrating deprecations triggered by Doctrine packages into its own error handler.

@beberlei, what do you think?

---

Oh, and: can we cover this change with a test? 😬

[ostrolucky]

With this option we would still have a problem about which package should set value of this env var by default. I don't think every user should configure this.

[mpdude]

☝🏻 just wanted to add this as well. Also, a bit surprising from a user‘s perspective since no other bundle/package/lib (that I am aware of) require setting env vars to have deprecations logged.

Not saying that it’s not a nice feature to be able to turn this on via env vars, just like other software allows to turn on error logging/debugging in a similar way.

[beberlei]

Good improvement

[greg0ire]

With this option we would still have a problem about which package should set value of this env var by default.

Maybe the idea was to use symfony/flex with an env configurator, in a recipe associated with doctrine/deprecations?

[ostrolucky]

That would add the line to .env file, wouldn't it? That makes sense for options that user often need to change, but here, I can't see why would any symfony user want to opt out from this, seeing they can't opt out from this behaviour in core symfony components, those always do @trigger_error. Is there some use case I am missing where you want to have mixed deprecation trigger mechanisms in a project? Maybe I am too pedantic here, in the end it's better than nothing. But i see this env var as something that every symfony frramework user will have in their .env file but nobody will want to change.

[greg0ire]

Quite unlikely to be changed indeed. Maybe the intended usage is something else, let's see.

[stof]

@ostrolucky if you want a no-configuration system for Symfony projects, it would require changing the default reporting mode of Doctrine to match the Symfony one. As long as defaults are not the same, we cannot have 0 configuration.

[nicolas-grekas]

Test case added, should be ready for merge.

About your concern for Symfony @ostrolucky, I think we first thought about adding a line in the default recipe, but you're raising a valid point. I think I'd suggest going with a line in FrameworkBundle::boot() instead then.

[greg0ire]

Thanks @nicolas-grekas !

[nicolas-grekas]

See symfony/symfony#50468 for Symfony