Problem/Motivation
In migration tests, the 'localize_d7_comment' migration is discovered, which needs d7_comment plugin.
This happens even in those tests where we do not run that specific migration.
The 'd7_comment' plugin is provided by 'comment' module which is not enabled explicitly in all the migration tests.
The migration is in config/optional, so it will only be loaded if all its dependencies are there.
Steps to reproduce
Proposed resolution
Instead of enabling the 'comment' module from every migration test, it should be a dependency of the migration.
This way, the migration will be skipped if 'comment' module is not present, thanks to how config/optional works.
Remaining tasks
User interface changes
API changes
Data model changes
Issue fork l10n_server-3553111
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 #3
donquixote commentedComment #4
donquixote commentedThe question was raised by Guiu what happens to the migration when we uninstall and reinstall comment module.
It is quite simple, because the migration is in config/optional:
(that is if the dependency is present as in the MR)
- When we uninstall comment module (if no migration has started yet), the migration config entity is gone.
- When we install comment module, while l10n_migrate is enabled, the migration config entity comes back.
I have not checked what happens if there is already a migration based on the config entity.
In my own experiment, the migration would not work anyway because I did not set up the source database.
However, there are some other observations:
- The l10n_migrate module currently depends on migrate_tools via l10n_migrate.info.yml. That module is not present via composer.json require-dev. This should be investigated further.
- To uninstall comment module, one must first uninstall fields that reference comments.
This said, I don'T see that any of the above would be a blocker to adding this dependency in the migration.
Comment #5
guiu.rocafort.ferrerComment #6
guiu.rocafort.ferrerI have tried that indeed, installing and uninstalling comment module causes the config object for the migration to be removed or installed.
Looks good to me, setting as RTBC
Comment #7
guiu.rocafort.ferrerComment #8
donquixote commentedBtw I don't really know if we need that "enforced" part.
vs
See https://www.drupal.org/node/2404447
From how I understand it:
If we would let Drupal save the migration config entity, then dependencies are re-calculated. Any non-enforced dependency can be lost, and new non-enforced dependencies could be added, based on the plugins being used.
Having the dependency "enforced" means that we are fully in control, and Drupal is not allowed to remove it when it re-calculates dependencies.
However, for migration config entities, we typically don't allow Drupal to do anything, we only edit them by hand. At least this is how I remember working with migrate_plus migration config entities.
So in our case there is no practical scenario when the "enforced" would make a difference. But it is still safer and more correct, if we manually add a dependency, that we add it as "enforced".
Comment #9
guiu.rocafort.ferrerIf the dependency is not declared as enforced, then uninstalling the comment module would not cause the configuration to be removed, and we will end up with migrations that depend on modules that are no longer installed, so it needs to be "enforced" to avoid that situation.
Comment #12
fmb commentedMerged, thanks!