[DI] Deprecate non-string default envs #27680
Labels
Comments
|
We should allow |
symfony-splitter
pushed a commit
to symfony/dependency-injection
that referenced
this issue
Mar 27, 2019
This PR was merged into the 4.3-dev branch. Discussion ---------- [DI] Deprecate non-string default envs | Q | A | ------------- | --- | Branch? | master | Bug fix? | yes-ish | New feature? | yes | BC breaks? | no <!-- see https://symfony.com/bc --> | Deprecations? | yes | Tests pass? | no <!-- please add some, will be required by reviewers --> | Fixed tickets | #27680, symfony/symfony#27470 (comment) | License | MIT | Doc PR | symfony/symfony-docs#... <!-- required for new features --> This is a failing test to further clarify the issues raised in #27680 So given symfony/symfony#27680 (comment) > We should be sure this solves a real-world issue. I think it solves a real bug :) Commits ------- 2311437c9f [DI] Deprecate non-string default envs
fabpot
added a commit
that referenced
this issue
Mar 27, 2019
This PR was merged into the 4.3-dev branch. Discussion ---------- [DI] Deprecate non-string default envs | Q | A | ------------- | --- | Branch? | master | Bug fix? | yes-ish | New feature? | yes | BC breaks? | no <!-- see https://symfony.com/bc --> | Deprecations? | yes | Tests pass? | no <!-- please add some, will be required by reviewers --> | Fixed tickets | #27680, #27470 (comment) | License | MIT | Doc PR | symfony/symfony-docs#... <!-- required for new features --> This is a failing test to further clarify the issues raised in #27680 So given #27680 (comment) > We should be sure this solves a real-world issue. I think it solves a real bug :) Commits ------- 2311437 [DI] Deprecate non-string default envs
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Symfony version(s) affected: 4.1
Description
Currently it's allowed to do define a scalar value for a default env parameter, e.g.
env(SOME): 1.5(opposed to its string value"1.5") while that's not possible with real env vars (hence we added the prefix processors). It's a trap and as such I think we should deprecate non-string defaults, and force string values in 5.0.This way we can safely imply a default
string:...processor again, and cast to i.e. float using its dedicatedfloat:...processor. It was reverted in #27470 to preserve BC (see #27455), but i tend to agree with @stof in #27470 (comment) this is not correct.cc @nicolas-grekas
edit: this also requires to forbid setting prefixed defaults, which is possible today but not handled as such. I'd keep this possibility closed until then... today those are silently ignored.
The text was updated successfully, but these errors were encountered: