Needs work
Project:
Drupal core
Version:
main
Component:
base system
Priority:
Major
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
25 Feb 2022 at 11:47 UTC
Updated:
27 Mar 2022 at 20:08 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
alexpottComment #3
alexpottHas to go on 10.0.x first.
Comment #4
alexpottHere's the contents on \Drupal\Tests\Composer\ComposerTest::testEnsurePhpConfiguredVersion
As we can see the assumption made about the contents of the require.php key are tested...
So the substr() here is safe to do.
Comment #5
xjmDoesn't Composer provide API for this?
I'm not sure we can always guarantee that the
composer.jsonconstraint will be in this format, can we? Edit: Crossposted with #4 which answers this.I don't think we should remove these docs; rather, we should change them to remind the developer to update both the Composer constraint and the constant if we keep it (or while it is retained as deprecated).
Comment #6
longwave> Doesn't Composer provide API for this?
This is pre-bootstrap and so I don't think we can rely on API, we are doing this before we have set up the autoloader even.
Comment #7
xjmSorry, #5 was half a thought. #6 is correct for the early bootstrap case -- that's why we hardcode the check there to begin with -- but I was wondering if we could do away with
MINIMUM_PHPentirely and just load it from the Composer constraint everywhere.Comment #8
xjmComment #9
alexpottI think the notes to remember to update both are covered by the line added:
And the existing test that's shown in #4 makes it impossible for them to get out of sync.
Comment #10
alexpottI like the idea in #7 of deprecating \Drupal::MINIMUM_PHP - I think we should do this in a follow-up because I'd want to focus on any performance concerns. The constant is used when any instance of ModuleExtensionList, ThemeExtensionList etc... are created. I don't think any of these are on the performance critical path but reading the json will definitely not be as cheap as the constant and potentially during a site install these thing might be created a lot.
Comment #11
xjmHm, to me, #9 does not explain anything. It expects the developer to read our minds about what the comment means. The previous comment told the developer exactly what to do, and we shouldn't remove that sort of explicit info.
Tagging for a followup for #10.