Still on Drupal 7? Security support for Drupal 7 ended on 5 January 2025. Please visit our Drupal 7 End of Life resources page to review all of your options.Problem/Motivation
Tweak package_manager/src/ProcessOutputCallback.php in a test context, because in a test context we may want Composer deprecations to cause test failures, so we are notified of upstream changes and can update our implementation to track upstream.
https://git.drupalcode.org/project/automatic_updates/-/merge_requests/71...
Steps to reproduce
N/A
Proposed resolution
Bring back what @omkar.podey's earlier MR716 for #3337667: Allow JsonProcessOutputCallback and other Composer runner callbacks to gracefully handle deprecated command options did previously:
if ($error !== '' && !str_contains($error, 'deprecated') && !str_contains($error, 'deprecation')) {
throw new \Exception($error);
}
… but only in a test context.
We already have prior art for detecting whether we're inside a test or not: \Drupal\package_manager\Validator\PhpExtensionsValidator::insideTest() (which is private static and can be copied in its entirety).
Remaining tasks
- Write a test that simulates
composershowing a deprecation error in its output; this test should expect an exception. - Make the test pass by ensuring that this exception is thrown when appropriate.
User interface changes
None.
API changes
None.
Data model changes
None.
Issue fork automatic_updates-3349004
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
wim leersBlocked on #3337667: Allow JsonProcessOutputCallback and other Composer runner callbacks to gracefully handle deprecated command options.
Comment #3
wim leersComment #4
tedbowNeeds proposed solution
Comment #5
omkar.podey commentedMaybe since
ProcessOutputCallback::getOutputis logging warnings usingwe can use the count for warnings to be sure that there aren't any new deprecations. But the logger is getting reset at multiple points so this might not be feasible.
Comment #6
wim leersDiscussed with @omkar.podey earlier today.
Comment #7
wim leersComment #9
omkar.podey commentedComment #10
wim leersLGTM! 👍😄 Thanks!
Comment #11
omkar.podey commentedComment #13
wim leersComment #14
wim leersWhy has this not been committed in >1 month time? 😬😳
Comment #15
phenaproximaWhy not indeed!
A few very small things, but otherwise this looks good.
Comment #16
omkar.podey commentedComment #17
phenaproximaDecided to make the test coverage a tad more thorough; assigning to @tedbow for final review.
Comment #18
tedbowComment #19
tedbowAnother way to solve this problem would be to ask composer( and maybe provide a PR) to add a
--no-deprectationsflag. Basically have composer fail if any deprecations are used. I am not sure how else you could write tests that rely on composer commands and be alerted to deprecationsComment #20
tedbowHey everyone. Thanks for all the work on this!
But I think we need to rethink why we need this issue at all.
Presumably we need this issue because we don't want to be surprised when Composer 3 out comes and have our code break because we are using deprecated options or commands that will throw exceptions in Composer 3. The other reason would be to be helpful to other developers that might be using the Package Manager API and using options or commands that we don't use and that also might be deprecated.
The best way to solve this would be to use a matrix of composer versions in our tests. Right now there 2 problems with this.
Because there are not any Composer 3 pre-releases and
\Drupal\package_manager\ComposerInspector::SUPPORTED_VERSIONrestricts Package Manager from using Composer 3 even it is was available there is zero chance right now anyone would be using Package Manager with Composer 3 and it will probably be a while.Since we are blocked on getting into Drupal core because of needed changes to Drupal.org infrastructure and related security reviews it is likely that by the time we get into Drupal core it will already be using gitlab actions and then we would be free to use it ourselves to run our tests on a matrix of Composer versions. We would probably want to do that anyways to avoid problem unrelated to declared deprecations such as we found in #3351594: As of Composer 2.5.5, `composer config` JSON-encodes boolean values
Even if core is not using Gitlab actions by the time we get into core we will still be an experimental module so I think it would be fine not to have warnings for Composer deprecations at that point.
I am postponing this issue for now and we can reopen when we get closer to getting into core if are not able to switch to Gitlab actions at that point