[REF] Require latest version of civicrm-asset-plugin

[seamuslee001]

ping @totten @MikeyMJCO

[demeritcowboy]

Maybe I need to do something in a different order but upgrading a pretty up-to-date D8/master site after making this change I get:

Subscriber Civi\CompilePlugin\Subscriber\ShellSubscriber::applyDefaultCallback for event post-compile-list is not c allable, make sure the function is defined and public

[seamuslee001]

@demeritcowboy can you make sure to a composer update on the composer-compile-plugin as well?

[demeritcowboy]

Yes thanks that was eventually what I did.

So maybe what this shows it that if it needs to happen in that order then people will need to know that unless there's a way to enforce order. I usually update in one go with one command so I dunno the order there might be semi-random. Or for example because composer often runs out memory some people break it into smaller steps, and might update one thing before another. Or, by now, people maybe just are used to having to fiddle every time and will eventually figure it out.

[demeritcowboy]

I just got the same error updating a git-based drupal 7 using git pull and then running composer install. It updates the plugin, but then I guess still uses the older version to do the compile? Does that make sense?

Gathering patches for dependencies. This might take a minute.
  - Updating civicrm/composer-compile-plugin (v0.7 => v0.8): Loading from cache
Package zendframework/zend-escaper is abandoned, you should avoid using it. Use laminas/laminas-escaper instead.
Writing lock file
Generating autoload files
1 package you are using is looking for funding.
Use the `composer fund` command to find out more!

 [RuntimeException]
  Subscriber Civi\CompilePlugin\Subscriber\ShellSubscriber::applyDefaultCallback for event post-compile-list is not
  callable, make sure the function is defined and public

Then if I just run composer install a second time it's ok.

[totten]

I just got the same error updating a git-based drupal 7 using git pull and then running composer install. It updates the plugin, but then I guess still uses the older version to do the compile? Does that make sense?

@demeritcowboy Aaah, that's interesting, and I think it makes a lot of sense. Some related bits of info:

• Going from composer-compile-plugin v0.7 to v0.8, the plugin did in fact remove ShellSubscriber.
• In the past, I've had similar problems where upgrading/downgrading a composer plugin caused an intermittent/transitional error. The first composer install would fail, but then subsequent calls would work fine.
• Upstream composer is preparing an upgrade to v2, which involves a change in the PluginInterface. In v1, the plugin gets a callback on activate(); in v2, it adds support for a deactivate() callback. There's a clarification that composer will now auto-de-register some common event-listeners (and expects you to explicitly de-register others). I suppose it stands to reason that there were holes/challenges with using v1's plugin-lifecycle.

I don't really know what we can do within composer v1, except try to keep the list of listeners the same in each version...

[totten]

Don't want to hijack this thread, but just another thought on that - I wonder if we might mitigate the plugin-upgrade by arranging the plugin code to reduce the odds that the listener-list cahnges in the future? To wit: instead of registering listeners as-needed, we could pre-register event-listeners with stub functions:

    return [
            ScriptEvents::PRE_INSTALL_CMD => ['onPreInstallCmd', ...],
            ScriptEvents::PRE_UPDATE_CMD => ['onPreUpdateCmd', ...],
            ScriptEvents::POST_INSTALL_CMD => ['onPostInstallCmd', ...],
            ScriptEvents::POST_UPDATE_CMD => ['onPostUpdateCmd', ...],
            PackageEvents::PRE_PACKAGE_INSTALL => ['onPrePackageInstall', ...]
            PackageEvents::POST_PACKAGE_INSTALL => ['onPostPackageInstall', ...]
            ...
        ];
    }

    public function onPreInstallCmd($e) { $this->validateTasks($e); }
    public function onPreUpdateCmd($e) { $this->validateTasks($e); }
    public function onPrePackageInstall($e) { /*stub; nothing to do*/ }

The stub functions would hang around in all versions, and any iterations should be internal to those stubs. Of course, in the near-term it could provoke the problem it aims to mitigate, so not worth it for live/1.0+ plugin. But composer-compile-plugin is still v0.x; if we make the change before freezing civicrm-core v5.31, then it won't affect many folks, and maybe we head-off similar problems in the future.

[totten]

So maybe what this shows it that if it needs to happen in that order then people will need to know that unless there's a way to enforce order. I usually update in one go with one command so I dunno the order there might be semi-random. Or for example because composer often runs out memory some people break it into smaller steps, and might update one thing before another. Or, by now, people maybe just are used to having to fiddle every time and will eventually figure it out.

I think what this highlights is that we don't have a good control/measure on the interplay between composer, the different downstream configurations, and Civi's upgrades. This is really the problem -- e.g. if our test-regimen tried running the composer-upgrade on several different permutations/configurations, then that would give us a clear signal on whether a PR like this is safe (or requires special intervention).

As it is, I'm not really sure there is a simple+representative way to test this pre-merge. I mean, we can mock-up a build with some repositories/forks/overrides, but it's fairly tedious and error-prone (esp for a one-time review-task).

So, for the bigger picture, I've opened: https://lab.civicrm.org/dev/drupal/-/issues/142

For the near-term, given that it's hard to test composer-distribution pre-merge....I'm inclined to go ahead with merging. I mean, this looks reasonable and fits everyone's intuition. If there are further kinks, they'll hopefully appear during RC...

[totten]

@seamuslee001 JFYI, it occurred to me that there is a problematic side-effect -- older D8 deployments (based on roundearth/civicrm-composer-plugin) would wind up with both plugins installed, which is problematic proposition (since their layouts+wiring are different).

Of course, we should try to keep this change, so I've posted an update to make them coexist better: https://lab.civicrm.org/dev/civicrm-asset-plugin/-/merge_requests/6