Problem/Motivation
I expressed several times the opinion that the Drush migrate runner should not be coupled to Migrate Plus. I see no reason why we would like to use migrations as configurables that are flooding the config storage. There's also the Group argument. I think that was inherited from the D6-7 Migrate module and was good thing for that era. But now we have migration tags, a more flexible way for grouping migrations.
Proposed resolution
Decouple the Drush runner from Migrate Plus moving it in a separate module either packaged in Migrate Tools (as submodule) or as a standalone module.
I already created an external module, Migrate Run, which is diverged from Migrate Tools and small parts from Migrate Plus, just as a PoC and because I need such a runner for my projects. But if we decide to move it as submodule of Migrate Tools, I would be happy to abandon it and merge it here.
Remaining tasks
Discuss, decide, implement.
User interface changes
N/A.
API changes
N/A.
Data model changes
N/A.
Comments
Comment #2
claudiu.cristeaComment #3
claudiu.cristeaComment #4
mikeryan#2752335: Properly integrate configuration-entity-based migrations with the core plugin manager will enable Migrate Tools to manage both configuration-entity-based plugins and plugins defined in the migrations/migration_templates directory.
Groups aren't just about grouping - they also hold shared configuration.
Comment #5
heddnI think at this poing that drush supports this but the UI doesn't. Nothing is stopping us from making this work in all places. Or am I speaking out of turn?