Hello all, it’s time for the biweekly migration subsystem meeting. The meeting will take place in slack in various threads. This meeting:
➤ Is for core migrate maintainers and developers and anybody else in the community with an interest in migrations
➤ Usually happens every second Thursday and alternates between 1400 and 2100 UTC.
➤ Is done on the #migration channel in Drupal Slack (see www.drupal.org/slack for information).
➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!
➤ Has a public agenda anyone can add to. #3456078: [meeting] Migrate Meeting 2024-07-18 2100Z)See the parent issue for an idea of the typical agenda.
➤Transcript will be exported and posted to the agenda issue. For anonymous comments, start with a 👤 emoji. To take a comment or thread off the record, start with a 🚫 emoji.
| Migrate Initiative Meeting |
https://www.drupal.org/project/drupal/issues/3506605 (edited) |
| Migrate Initiative Meeting |
(Original Request) https://drupal.slack.com/archives/C226VLXBP/p1741875653779289?thread_ts=... (edited) |
| benjifisher |
I worked on this issue, so we need someone else to review it. |
| benjifisher |
This is one of the things we want to get done before we remove the migrate_drupaal module in D12. |
| mikelutz (he/him) |
I looked at it the other day. seems fine except we don’t need the source module annotation in the new plugin. |
| mikelutz (he/him) |
Think I typed that up and never hit enter. |
| benjifisher |
It looks to me as if it uses attributes, not annotations. Even the first commit in the MR uses attributes. |
| Migrate Initiative Meeting |
No issue yet. This is the first time I have brought this up. |
| Migrate Initiative Meeting |
(Original Request) https://drupal.slack.com/archives/C226VLXBP/p1741876203861139?thread_ts=... (edited) |
| benjifisher |
In the last meeting, we talked about editing migrations in the admin UI. If we want to do that, then we should provide a way to validate the choices made in the UI. First step: what are the configuration keys. Next step: how do you validate the config values? |
| benjifisher |
The source plugins already have the fields() method, which could be used in this way. |
| mikelutz (he/him) |
I’ve long wanted to have process plugins declare expected config and expected input and output |
| benjifisher |
But all plugins (source, process, destination, field) have config. All we currently do is document it, including "see the parent class for additional configuration options". |
| benjifisher |
Maybe this is a question for the larger plugin system, not just migration. |
| benjifisher |
... expected input and output
A long time ago, @marvil07 suggested using the TypedData system to declare that. I am not sure how that would work. |
| marvil07 |
It sounds handy to have validation on configuration for migration plugins.
AFAIR I tend to add validation on the constructor of the plugin, which is not ideal.
Having it as part of normal validation would be great. |
| marvil07 |
On the expected input/output, that may be a separate issue, and is specially useful for migrate process plugins.
Right now, AFAIK, the assumption is the same as unix programs, text is the interface passed along the pipes.
That is quite nice, but there may be useful cases to pass other things, like the dom plugin set we added with @benjifisher a while ago.
Not sure about the actual solution for that.
IIRC I did ask Berdir about using typed data there, but I totally forgot now what was the outpus of that conversation :sweat_smile: , my memory suggest that it was an idea that was discarded. |
| dinarcon |
Somewhat related to a previous conversation https://drupal.slack.com/archives/C226VLXBP/p1637271127038900 |
| benjifisher |
I am thinking about how to implement the validation. If you pass an array of configuration to the plugin's constructor, then could the constructor create a config entity (without saving any config to the database) and validate that, using the config validation system? Would the plugin declare/decide which schema to use, or would the schema declare that it applies to the plugin? |
| dinarcon |
I was originally thinking of just listing configuration options, not validating them. In some cases, configuration options are exclusive. Not sure the config validation system can handle that unless we use custom constraints. |
| marvil07 |
@benjifisher that's a good point, the how may be not yet clear, but happy to see interest about this. It may be worth moving this conversation to an actual issue. I may get to implement a draft over dcon if someone does not beat me (that is totally OK!) |
| marvil07 |
Ah sorry for the channel echo, unintended :see_no_evil: |
| Migrate Initiative Meeting |
https://www.drupal.org/project/drupal/issues/3171980 |
| Migrate Initiative Meeting |
(Original Request) https://drupal.slack.com/archives/C226VLXBP/p1741876445861569?thread_ts=... (edited) |
| benjifisher |
All of that will be removed along with the migrate_drupal module. OTOH, it is a very small change: +7 -5, with most of the changes in tests. |
| benjifisher |
Back in 2020, @mikelutz (he/him) set it to NW for tests. Are the test changes just fixing tests broken by the change or are they actually testing the intention of the change? A quick look at the MR is not enough to decide. |
| benjifisher |
@smustgrave: There are 7 issues in the NR status for the migration system, and I already started threads for a few of them. Why do you call attention to this one in particular? |
| smustgrave |
Just happened to be the one I had open :) certainly can wait till next meeting. But the code it’s changing I definitely dont think I can review it |
| mikelutz (he/him) |
Well, at the time this was a bug and the policy was all bug fixes required a test showing the bug. |
| mikelutz (he/him) |
So if a warning was being emitted during the migration, I wanted it captured in a test. |
| mikelutz (he/him) |
I think I still do, but I can add this one to my list. |
Comments
Comment #6
benjifisherComment #7
smustgrave commentedAppears all threads have been captured.