ScaffoldFilePermissionsValidator should use ComposerInspector instead of ComposerUtility

I think this one will need input from #3334994: Add new InstalledPackagesList which does not rely on Composer API to get package info, as we need list of installed packages.

This now blocks #3338346: Do not allow drupal/core-composer-scaffold to be used by packages other than core.

#3334994: Add new InstalledPackagesList which does not rely on Composer API to get package info landed, this should now be able to move forward.

While we should still get that input from @tedbow, meanwhile this MR can be rebased on top of #3334994: Add new InstalledPackagesList which does not rely on Composer API to get package info! 👍

@omkar.podey add an issue summary here? thanks

Regarding #6, I discussed this with @tedbow.

I did a little experimentation to see if a Composer plugin could alter the file mapping defined by drupal/core, that gets written to installed.json and composer.lock.

The answer is yes, it could be done, if the plugin did something similar to what cweagans/composer-patches used to do. I don't, however, think that's especially likely to happen.

The real problem is that we do not properly account for the overridability of scaffold file mappings supported by the scaffold plugin, and we never have. I've opened a post-MVP issue to deal with that.

For that reason, @tedbow and I agreed that it's okay for us to change the validator to call $composerInspector->getConfig('extra.drupal-scaffold.file-mapping', $installed_packages['drupal/core']->path). Doing that will get the file mapping defined by core, which is not guaranteed to be complete or accurate for the actual project using Package Manager -- but it also doesn't make the current situation any worse. And it helps get us off of ComposerUtility.

Yeah, that sucks...composer.lock isn't there in core's directory (and rightfully so), and therefore ComposerInspector::validate() throws an exception when it tries to validate that. The only real way out of this pickle is for us to stop requiring the presence of composer.lock, but that means we can't get the types of installed packages until Composer merges and tags https://github.com/composer/composer/pull/11340. Maddening.

Here's what I would suggest: we should change validate() so that it doesn't require composer.lock to exist, but getInstalledPackagesList() does. I think this is a reasonable course of action because a) it doesn't change or complicate our API, and b) getInstalledPackagesList() is the only thing that needs to deal with composer.lock.

Traced into some of the failures and the reason why it's going to keep failing is because the changed scaffold file mapping has to be defined in path/to/stage/dir/vendor/drupal/core/composer.json. Not installed.json, which is where ComposerUtility would read it from.

Hopefully the fixture manipulator is smart enough to do that...

Discussed in detail during meeting just now. Conclusion: this is hard-blocked on direction from @tedbow in #3343827: Update FixtureManipulator to work with InstalledPackagesList, real composer show command to avoid wasted work.

#3343827: Update FixtureManipulator to work with InstalledPackagesList, real composer show command landed, this is unblocked!

This should wait for #3345633: Remove FixtureManipulator::modifyPackage() last usage to land, because otherwise duplicate changes would need to be made here.

This patch will pass once #3345633: Remove FixtureManipulator::modifyPackage() last usage lands.

+++ b/src/Validator/ScaffoldFilePermissionsValidator.php
@@ -27,13 +27,17 @@ final class ScaffoldFilePermissionsValidator implements EventSubscriberInterface
-   * Constructs a SiteDirectoryPermissionsValidator object.
+   * Constructs a ScaffoldFilePermissionsValidator object.

😅

I have no objections to this code. Committing when tests pass.

No it didn't. We're just positively plagued by these pestilential random failures.

And, committed!

Only one (or two) things left to do, and ComposerUtility is gone.

That means #3338346: Do not allow drupal/core-composer-scaffold to be used by packages other than core is now unblocked! 👍