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.

We are doing some issue management housekeeping and adding/removing components.

We are removing the "Other Submodules" component and want people to categorize issues with the best module/submodule component.

Moving this issue to "AI ECA".

See 📌 Update AI module project components Active for more details.

Actually, task makes more sense

Target 1.2.x for this.

The AI/ECA integration → module is now ready to go with AI 1.2 and later. So, it's now time to finalize this issue as well by removing the deprecated code and finish the upgrade path.

Before I get this done, I'd appreciate one confirmation: we keep the submodule as is in AI 1.1.x, and only remove it from 1.2 and later, right?

We have never actually done a depreciation notice for it yet, this issue was to prepare that.

So I think we still need a stub module and a update hook for 1.2 release and then full removal in 2.0, unless there is some nice way of doing the upgrade in some other way?

1.1.x we just keep as is.

Thank you @marcus_johansson, this is great. I'll get the MR up-to-date following those guidelines.

I've rebased the MR and then implemented the suggestions from the MR-review. What's left after merging this, is just the info and the install file, everything is gone as it then lives in the new module. From that point on, the submodule hangs around until AI 2.0 where it can then be removed entirely. From my point of view, we can go that far, as an upgrade path is available, so users won't lose anything by this process.

As I'm not a maintainer here, I can't close the threads in the MR, so @marcus_johansson please close them if you're OK with them.

Note: the failing phpunit test doesn't seem to be related to this MR.

Thanks you - tested on clean 10.5 and 11.2 environments and the upgrade process works well.

I added a follow up issue for the test failure here 🐛 Figure out random failures of testTokenCount test Active . Seems like retriggering is working.