Port AMA install process from ACLI to Drupal

Started a draft MR.

Need a day or 2 to finish the rest if we're agreed on the direction.

This looks interesting for sure, but also makes me wonder .

It can't be added to existing Drupal 9+ sites.

… and for good reason. An existing site may already have migrations in progress, may have already created custom configuration, and so on. Lots of data stored in the DB can already be tightly coupled to the exact code being executed, and retroactively applying patches to modules can cause the state of the DB to get out of sync with the state of the codebase.

It adds a barrier to entry for people unfamiliar with CLI stuff.

But installing this module already requires Composer. This new command makes it even more difficult, because there can be many ways the Composer commands will fail. Whereas with the single ACLI command, it's guaranteed to succeed.

It requires maintaining logic in a separate project outside of Drupal.

Yes, and intentionally so:

• generating a Composer project is a VERY different concern (ACLI: https://github.com/acquia/cli/commit/54ce971393436a50a220f49fb4da93f8323...)
• maintaining recommendations for a given major Drupal version is also a VERY different concern: (D7 → D9: https://git.drupalcode.org/project/acquia_migrate/-/tree/recommendations and D7 → D10: https://git.drupalcode.org/project/acquia_migrate/-/tree/recommendations-10)

The MR as it currently stands is removing/reducing the separation of concerns. That's a strong concern for long-term maintainability.

Port AMA install process to Drupal from ACLI.

I can only accept such functionality if you can prove that it's safe.

Allow people to install and configure AMA like any other Drupal module.

But it isn't.

Support mglaman/composer-drupal-lenient to optionally allow composer installable dependencies based on patches or MRs before they have D10+ versions. This will get increasingly important moving in to D11+ soon.

There's not much value to doing this, because the probability is VERY high that any module that was written for Drupal 9/PHP 7.4 will not work correctly on Drupal 10/PHP 8.1 … especially when it comes to migrations. And migrations is exactly what AM:A is about.

The very point of AM:A is that it provides a solid, reliable starting point. This requires at minimum a successful Composer install with a working empty Drupal site (which this definitely would make likely to fail) and modules preinstalled whose migrations have been vetted (which this seems to be changing too?).

Test coverage could go a long way in convincing that this is in fact reliable 😄🙏

Next steps

1. Documentation/architectural rationale for why this is safe
2. Explain how this does not reduce maintainability
3. Test coverage!

Understood Wim -- I think we just have 2 contrasting approaches to development, neither wrong or right.

We'll work on some of these changes on a separate fork or branch and offer to merge later after a proven outcome.

jienckebd → closed merge request !57