Move module config exclusion from config_environment to core.services

Some thoughts about the documentation text:

Excluded modules [...] are not exported when exporting all configuration.

Technically speaking, modules are never exported; What happens is that the enabled-status of an excluded module is not exported. But probably if we write that, we would be over-complicating things?

It is possible to exclude required modules [...]

To me, the phrase "it is possible" sounds as if it could be considered in certain situations. However, I think you intend to explain why people should never do this, right? I suggest something like "While it is technically possible to exclude required modules, that would mean that the exported configuration can not be imported anymore." Or maybe even "For instance, it is your own responsibility to never exclude required modules, because it would mean that the exported configuration can not be imported anymore." (PS. "anymore" is one word in this context.)

I don't think the third paragraph needs the "Note:" prefix, the text is just as good without it. I would even argue that it is more important than the second paragraph, so the 2nd and 3rd could be swapped around.

https://www.drupal.org/project/drupal/issues/2991683 is now in "Reviewed & tested by the community" state.

++ for config_exclude functionality available to everyone with no experimental module needed !

Keep me posted for when we need to review this one also. :)

Reviewed 3079029-9-review-do-not-test.patch looks fine.

Manual review and test

$ git apply 3079029-10-full.patch
$ drush cr
Cache rebuild complete.                                                                                                                                                                                                                              [ok]
$ drush cex
The active configuration is identical to the configuration in the export directory (sites/default/files/config/sync).                                                                                                                                [ok]
$ rm -rf sites/default/files/config/sync/*
$ drush cex
Configuration successfully exported to sites/default/files/config/sync.                                                                                                                                                                              [success]
$ ls sites/default/files/config/sync | wc -l
320

Also the site functionality seems to be working fine.

#2991683: Move configuration transformation API in \Drupal\Core\Config namespace is in.

I haven't reviewed the full patch here, but I can't see anything yet to uninstall / deprecate config_environment module.

We would want to do something like the following:

1. Mark it hidden
2. system_update_N() to uninstall it
3. hook_requirements() to prevent it being reinstalled.

Or if sites already using the module need to take action, we might want to do only #3 (with an additional runtime warning when it's installed).

Also a follow-up to actually remove it wholesale in 9.0.x

edit: spoke to bircher in slack. While config_environment will be empty after this patch, there's still a use for it as an alpha experimental module for more config_environment work still to do. So what we actually want to do is completely remove it from 8.8.x and recommit it to 8.9.x/9.0.x as an empty alpha experimental module again. That means the patch here is fine, but I think we should have an explicit followup for the removal since it's an unusual reason to remove an alpha module (normally we'd do that if development is abandoned or it's been deprecated).

1. +++ b/core/assets/scaffold/files/example.settings.local.php
   @@ -129,3 +129,25 @@
   + * Excluded modules and all the configuration that directly and indirectly
   + * depends on them are not exported when exporting all configuration. When
   + * importing the configuration the excluded modules and their configuration
   + * are not removed when they currently exist in the active config but are not
   + * part of the configuration to import. This affects only the configuration
   + * synchronisation, single import and export of configuration is not affected.
   
   +++ b/sites/example.settings.local.php
   @@ -129,3 +129,25 @@
   + * Excluded modules and all the configuration that directly and indirectly
   + * depends on them are not exported when exporting all configuration. When
   + * importing the configuration the excluded modules and their configuration
   + * are not removed when they currently exist in the active config but are not
   + * part of the configuration to import. This affects only the configuration
   + * synchronisation, single import and export of configuration is not affected.
   

   I think this can be a bit clearer. Something like:

    * Excluded modules and all the configuration that directly and indirectly
    * depends on them are not exported when exporting all configuration. When
    * importing configuration, if excluded modules are installed, they are not
    * uninstalled and their configuration is not removed from active config. This
    * affects only configuration synchronisation, single import and export of
    * configuration are not affected.
   

+++ b/core/assets/scaffold/files/example.settings.local.php
@@ -129,3 +129,25 @@
+ * This is an advanced feature and using it means opting out of some of the
+ * guarantees the configuration synchronisation provides.
+ * It is not recommended to use this feature with modules that affect Drupal in
+ * a major way such as the language or field module.

+++ b/sites/example.settings.local.php
@@ -129,3 +129,25 @@
+ * This is an advanced feature and using it means opting out of some of the
+ * guarantees the configuration synchronisation provides.
+ * It is not recommended to use this feature with modules that affect Drupal in
+ * a major way such as the language or field module.

Let's re-flow this comment. to make use of the space.

 * This is an advanced feature and using it means opting out of some of the
 * guarantees the configuration synchronisation provides. It is not recommended
 * to use this feature with modules that affect Drupal in a major way such as
 * the language or field module.

+++ b/sites/example.settings.local.php
@@ -133,12 +133,11 @@
+ * When exporting configuration, excluded modules and all dependent
+ * configuration are not included. When importing configuration, if excluded

'excluded [..] are not included' is a bit tautological.

What about 'When exporting configuration, the configuration objects and core.extension.list items for excluded modules will be removed from the final export.

+++ b/core/assets/scaffold/files/example.settings.local.php
@@ -129,3 +129,24 @@
+ * configuration are not included. When importing configuration, if excluded
+ * modules are installed, they are not uninstalled and their configuration is
+ * not removed from the active configuration. This affects only configuration
+ * synchronisation; single import and export of configuration are not affected.
+ *

Also 'if excluded modules are already installed' might be better here. Otherwise it sounds like excluded modules are being installed when configuration is imported.

As an outsider I find this explanation a bit confusing.

+++ b/sites/example.settings.local.php
@@ -133,12 +133,11 @@
+ * When exporting configuration, excluded modules and all dependent
+ * configuration are not included. When importing configuration, if excluded
+ * modules are installed, they are not uninstalled and their configuration is
+ * not removed from the active configuration. This affects only configuration
+ * synchronisation; single import and export of configuration are not affected.

I'd keep it (maybe to) simple:

On config export sync, no config or dependent config of any excluded module is exported.
On config import sync, any config of any installed excluded module is ignored.

hmm I actually like #21 but we might want to do a combination of both, something like this:

"On config export sync, no config or dependent config of any excluded module is exported.
On config import sync, any config of any installed excluded module is ignored.

In exported configuration, it will be as if the excluded module had never been installed. When syncing configuration, if an excluded module is installed, it will not be uninstalled by the configuration sync, and dependent configuration will remain intact."

Committed 1d8712f and pushed to 8.8.x. Thanks!

Credited everyone for the discussion on the comment.

Yay CMI 2.0 has got something in core as stable. win! Great work everyone!