Confusing duplication of container parameters in core.services.yml and default.services.yml

The reason is that default.services.yml is there is to have a place to document values and what you could change them to, similar to settings.php

core.services.yml is there in order to provide default values

Yes, default.services.yml isn't ever used.

services.yml is. Which is copied from default.services.yml at installation time. If a new value is added to default.services.yml and not core.services.yml, then your site would explode with an exception until you copy default.services.yml again, figure out what is new, what are changed defaults and what you changed...

Having it in core.services.yml allows us to introduce new parameters without it being an API change.

KTB does not setup a Drupal site, it just setups a kernel + container so core/lib is the only thing it should care about.

<ad>KTBTNG</ad>

Also: if I read "default", then I think it's going to be used.

Well, this is not something new but rather exists since EVER in Drupal. I think changing this now is wrong.

Its though tricky to document anything inside the default... files because they are copied and so would need to be adapted. Sadly we don't have a docs aware yaml en/decoder, so we would have to deal with some from of string manipulation.

Honestly ideally default.services.yml/default.settings.php should be in /sites instead. This could remove a lot of the confusion, I think.

Yes, #4 simulates the installer, which copies that file.

It's not used during *runtime*

Theoretically we could just rely on sites/default.services.yml and load that directly before the site specific sites/default/services.yml.

Then the defaults would indeed be taken into account, but current the default file is not defaults, but sample / example values.

The code internally needs to ensure that the defaults are taken into account.

Changing that would have the consequence of no longer e.g. controlling the session.storage.config parameters via PHP configuration, which currently with an empty default.services.yml would be possible.

For now @Wim the magic word is:

"upgrade path"

e.g. you update from beta13 to beta14 and because you don't have 'smart_cache_options' parameter, which is in sites/default/default.services.yml, but not in core/core.services.yml, your site explodes on next cache rebuild as you cannot build the container _until_ you have manually copied the new value from default.services.yml to services.yml ...

I propose that we:

1. Move the documentation of individual container parameters that's currently in default.services.yml into core.services.yml.
2. Replace default.services.yml with just documentation that says to look at core.services.yml and module *.services.yml files to find stuff that a site maintainer might want to customize, and then whatever the site maintainer wants to customize, it can paste there (where "there" is the /sites/FOO/services.yml that got made during installation from default.services.yml) and modify as desired.
3. Open a separate issue to move default.settings.php and default.services.yml from /sites/default to somewhere else, such as /core/install, or wherever it would not be confused with the site's actual settings and services or anything else that affects runtime behavior.

Disagree with #9. core.services.yml is massive, and contains dozens of services that 98.4% of developers have no reason to touch, ever, much less when picking up D8 for the first time. The values in default.services.yml are "buttons and dials you're supposed to twiddle", which is a good place for the documentation for them. (You can twiddle various other buttons and dials from core.services.yml or other module services.yml files, but the ones that we specifically expect/want you to twiddle should be called out especially.)

Moving the default/example files to elsewhere is fine; I don't much care there as long as we document it.

You can twiddle various other buttons and dials from core.services.yml or other module services.yml files, but the ones that we specifically expect/want you to twiddle should be called out especially.

I don't think HEAD's current default.services.yml is making good choices for what it's exposing from core.services.yml vs. what it's not. I don't think renderer.config is a dial that should be twiddled by any more than 1% of sites. twig.config also seems silly to include in the file that is intended for production settings when all of the options have a warning to not use on production; seems like that should all move to development.services.yml. I can see the logic in having factory.keyvalue in the file as a likely dial to want to twiddle, but I think there's an even greater use-case for twiddling $settings['cache'], which is not in default.settings.php, nor is its D7 equivalent in D7's default.settings.php.

So in its current form, I think default.services.yml doesn't make much sense, but improving it to make better choices in what it exposes would also be a fine way to resolve this issue.

renderer.config is a dial that should be twiddled by any more than 1% of sites.

Come on, this is no different AT ALL to default.settings.php. How many sites will need to change the bootstrap config?

Nominally anything in core.services.yml can be overridden by the site's services.yml file. Including everything.

Proposal: Things in the default/example file should be those that we expect/anticipate/want, say, 30%+ of sites to be messing with. Things we expect them to do. Put them there, document them there, but still have a default in core.services.yml to ensure there's always a value no matter what. For the 1% case, leave that in core.services.yml and document THERE what it does. The 1% who care can find it there and figure out what to do.

> The reason is that default.services.yml is there is to have a place to document values and what you could change them to, similar to settings.php

> Yes, default.services.yml isn't ever used.

This and the rest of #2 should be addedf to default.services.yml as documentation.