Deprecate internal ECA-module

What we did for the providers may be useful here: ai_update_10301() checks the various possibilities for whether the deprecated or replacement module exist and are enabled and reacts accordingly. Something similar would be useful for ai_eca as well as deprecating the module.

Aha, that's very useful, thank you!
I'll take a look and create something similar.

It seems to be more complicated than the providers: I made the mistake of registering a contrib module with the same name as the submodule. When the submodule is enabled, and composer downloads the new one, Drupal automatically uses the contrib one, without uninstalling the original. This means you can't run hook_update from the submodule or hook_install from the contrib one.

Perhaps it's easier if I register a new contrib module, something like "ai_integration_eca" and then apply the provided example...

I have tried to search for solutions for this as well this morning, but I can't find a good solution that doesn't require you rename it.

You can't control the discovery as far as I could tell, like I think you could in Drupal 7 via system table.

The only way I can think of to test is if we add the module as required module in composer.json and remove/rename the old module completely. But since ECA is a requirement for AI ECA, that would lead to a lot of dependencies being downloaded.

With a renamed module we already have a proven upgrade path. It kind of sucks, to have to rename it, but I'm not sure if there is some other way around.

Yeah, no problem. I should have thought about that when I registered it in the first place... #facepalm

I have some time tonight, I hope I get it done.

@marcus_johansson, the PRs for the related modules are done. Let me know how you want to address this in terms of timing (when I should create new releases etc.).

@lammensj - I wrote some comments. Could you have a look, maybe its just NIT and not important or maybe I misunderstood something, but its good to get clarity. Could you also move the MR to point to 1.1.x-dev

I think 1.1.0 would be released when this is ready, together with the suggested solutions for Structured Responses and Function Calling, since all of those are (none-breakign) architectural changes. Maybe as soon as next week.