[Console] Runtime conflict for psr/log >= 3.0 instead of composer conflict #43884
Conversation
c0b3a60 to
7af9ba0
Compare
|
Well, to me, letting the solver know about the conflict is better than forcing the user to manage dependencies manually. Cases where the latest versions of packages are incompatible together need to be resolved by the user anyway to choose which requirement they want to relax, but that's only happening properly if the solver knows about the incompatibility. |
There was a problem hiding this comment.
I think, no matter how we deal with this issue, there will be a group of people dissatisfied with our solution. Currently, we have a well documented incompatibility that should be easy to resolve. Moving this to a runtime check feels like we're doing the job Composer should've done.
I'm not convinced we should make this change.
|
Shouldn't we have a mix here? This exception in 5.3 and the conflict in 5.4? What about moving the check to the constructor though? |
Good point. If we restore the conflict in 5.4, I'm 👍
That wouldn't work because the class definition itself raises a fatal error, doesn't it? |
|
Thank you @fancyweb. |
This PR was merged into the 5.4 branch. Discussion ---------- [Console] Restore psr/log >= 3.0 conflict | Q | A | ------------- | --- | Branch? | 5.4 | Bug fix? | no | New feature? | no | Deprecations? | no | Tickets | #43884 (comment) | License | MIT | Doc PR | - Commits ------- 5c65796 [Console] Restore psr/log >= 3.0 conflict
ConsoleLoggeris not compatible withpsr/log >= 3.0but it's an optional feature andpsr/logis an optional dependency in the Console component. Yet, having a real "composer conflict", preventssymfony/consolefrom being updated above the5.3.2version if a previous dependency has already installedpsr/log 3.0. But I'd rather have an updatedsymfony/consoleversion andpsr/log 2.0since thepsr/logchanges are just about types.