Unable to uninstall wxt_ext_blog once it is installed, other wxt_ext_* modules also unable to uninstall.

To get around this in the past I've removed the dependency entries in wxt_ext.info.yml manually (and possibly other modules, can't recall which but wxt_ext_password_policy also affected, rebuilt caches and re-uninstall works). Wondering how to best improve this situation for DX (developer experience).

This also becomes an issue when using configuration splits , say you don't want wxt_ext_password_policy in your dev environments, only in production, well, you'll get issues splitting this and uninstalling wxt_ext_password_policy when switching from live split to dev split.

I have seen the same issue.

see patch for example

This patch probably should allow wxt_ext_blog to be uninstalled, I will re-test again and make adjustments if needed.

actually this patch does allow wxt_ext_blog to be uninstalled although I'm not sure exactly why wxt_ext_group is involved but the patch works for this use case.

basically for other wxt_ext_? modules they all seem to have a similar issue.

We've had to put in a similar patch to be able to uninstall the password policy wxt_ext_password_policy for config split for example, we did not want this policy in dev and had to remove hard coded dependencies to be able to uninstall it without forcing the uninstall of wxt_ext which basically will try to uninstall every wxt module.

to avoid this problem dependencies had to be removed from profiles/wxt/wxt_ext/wxt_ext.info.yml and sometimes others such as for wxt_ext_blog.

To avoid this type of situation perhaps hook_install could be used instead if other modules are needed after installation and if necessary some hook_uninstall
? this coupled with removing dependency entries in the wxt_ext/wxt_ext.info.yml

The intent for wxt_ext was to facilitate an easy way in CI to enable all of the modules.

If you disable wxt_ext itself it should just leave you with the individual wxt_ext_* modules still installed but you could use a la carte.

At that point I'm definitely happy to see if we can tighten the dependencies up and make the experience better with config split etc :)

@sylus, my appologies, I corrected the first sentence. With that said, ya it's a bit of a tough one. For now just leave it as there is a fairly simple workaround which is to edit the .info.yml files in question and remove the hard coded dependencies the time it takes to do this. Patches can be written for specific use cases.

Perhaps we sit on this for a while and think about it.