Add a development.services.yml for development

1. +++ b/core/lib/Drupal/Core/DrupalKernel.php
   @@ -526,8 +526,8 @@ public function discoverServiceProviders() {
   -      $this->serviceYamls['site'] = $GLOBALS['conf']['container_yamls'];
   +    if ($container_yamls = Settings::get('container_yamls', array())) {
   +      $this->serviceYamls['site'] = $container_yamls;
        }
   
   +++ b/sites/example.settings.local.php
   @@ -17,6 +17,13 @@
   +if (file_exists(DRUPAL_ROOT . '/' . $conf_path . '/local.services.yml')) {
   +  $settings['container_yamls'][] = DRUPAL_ROOT . '/' . $conf_path . '/local.services.yml';
   +}
   

   Can we add a @todo to use imports in services.yml in the future? In that case you would need to adapt the settings

2. +++ b/sites/example.local.services.yml
   @@ -0,0 +1,11 @@
   + services:
   +  cache.backend.memory:
   +    class: Drupal\Core\Cache\MemoryBackendFactory
   +  cache.backend.null:
   +    class: Drupal\Core\Cache\NullBackendFactory
   

   indentation needs one more space, sorry

Thank you! Adding all the tags.

Let's add the example for how to disable render cache to example.services.local.yml - I think we can do this by overriding cache.render cache factory (not sure about that)

Let's add the example for how to disable render cache to example.services.local.yml - I think we can do this by overriding cache.render cache factory (not sure about that)

The "configuration" could be moved properly from Settings() to the yml file once #2315613: Add a development.services.yml for development is in.

+++ b/sites/example.services.local.yml
@@ -0,0 +1,11 @@
+# of 'sites/yoursite.com/services.local.yml' and uncomment the commented lines

shouldn't this mention rather settings.local.php ?

I've got a stupid question but if we move /sites/example.settings.local.php to /sites/default/settings.local.php. Will leaving the services.local.yml still work from /sites/? *haven't checked what's in $conf_path*

I've been moving those files by habit but maybe I don't even need to do that anymore?

Tempted to bump this to critical. I have no way to turn off render caching right now, which pretty much stops all dev work in its tracks.

1. +++ b/core/lib/Drupal/Core/DrupalKernel.php
   --- /dev/null
   +++ b/sites/example.services.local.yml
   
   +++ b/sites/example.services.local.yml
   @@ -0,0 +1,11 @@
   +# that mention 'services.local.yml'.
   
   +++ b/sites/example.settings.local.php
   @@ -17,6 +17,14 @@
   +  $settings['container_yamls'][] = DRUPAL_ROOT . '/' . $site_path . '/local.services.yml';
   

   services.local or local.services?

2. +++ b/sites/example.settings.local.php
   @@ -17,6 +17,14 @@
   +$settings['cache']['bins']['render'] = 'cache.backend.null';
   

   Won't this break if the local.services.yml is missing?

Won't this break if the local.services.yml is missing?

Let's put that into the if() as well?

It will fail being in the if() as well as being outside if the local.services.yml/services.local.yml doesn't have that null backend definition. (unlikely but still possible I think.)

I was thinking about mentioning that one too. Though I'd like to know there is something wrong and not fail silent, how about yous?

isn't it similar to #2241633: Simplify site-specific service overrides?

There is also #2244807: Replace $GLOBALS['conf']['container_yamls'] with optional $conf_path/services.$env.yml file

And this issue is also doing something with services.yml #2241581: Simplify site-specific (development) active/runtime config storage

I'd written this review yesterday, but I didn't notice posting it failed:

This issue should update the https://www.drupal.org/node/2259531 change notice.

One downside of this patch is that you'll have to copy and rename *two* files instead of one. But it seems like everybody is okay with that, because it'll give us a cleaner container.

I think the instructions at the top of example.settings.local.php also might want to refer to the instructions in example.services.local.yml, because right now, the instructions at the top of example.settings.local.php will allow you to use everything in it. With this patch, only a *subset* of the functionality provided by example.settings.local.php will actually work if you follow the instructions at the top.
The instructions at the top of example.services.local.yml are also wrong: the lines to uncomment aren't in settings.local.yml but in settings.local.php (i.e. this is a typo) and those lines don't live at the bottom, but somewhere in the middle-ish, and actually those lines are uncommented by default.
The solution for the combination of those problems is I think lies in putting the full instructions at the top of example.settings.local.php, because the user has all the instructions for all functionality provided by example.settings.local.php in that one place. example.services.local.yml could then refer to that.

#2309575: [Revert] Remove the null and memory backend definitions from core.services.yml in favour of devel module providing them instead was reverted. I think it makes sense to recommit it as part of this patch, since this patch provides the solution.

Because #2309575 was reverted, #26 no longer applies. Rerolled, included the changes from #2309575 in this patch, and fixed my own nitpicks.

Nice, though can we please drop the memory and null backend again from the main container?

Next issues we need: #2251113: Use container parameters instead of settings #2284787: Allow yml files to nominate imports

#32: Oh, OOPS! Great catch.

Thanks for linking to those next issues!

gtg now. More to be done in the other issues.

So to disable render cache all one would need to do would be to paste

$settings['container_yamls'][] = DRUPAL_ROOT . '/sites/example.services.local.yml';
$settings['cache']['bins']['render'] = 'cache.backend.null';

into your current settings.php file?

#35: Yes.

I disagree with the approach of providing a settings.local.php that needs work.

and #35 makes clear why:

This should just be available in core as

$settings['container_yamls'][] = DRUPAL_ROOT . '/sites/development.local.yml';

On the other hand this would belong to devel, but can devel add new services directly?

I am still in favor of providing DX config files per default that devel can extend instead of pushing all devel things to contrib.

Leaving RTBC as others might feel differently.

EDIT:

I think this is a case of "eating own dogfood". Every core developer will have something like that, which means any developer depends on devel, etc. or needs to follow this setup. I think the setup should be as simple as possible to get up and running for -dev.

Every time I come back to core dev the setup is a little different and new things are to change ...

#37: It's not entirely clear to me what you're saying. The recommended way is by using example.settings.local.php — the instructions for that can be found at https://www.drupal.org/node/2259531, and it's been that way for 3 months now. #35 is an alternative way to do it.
Can you clarify what you dislike and how you think it should work?

#38: I dislike that now I can't just plug in the settings.local.php, but that I have to:

- copy settings.local.yml as well

or I probably get WSOD.

That means I can't just copy the one file and am set, but I need to read the example.settings.local.yml and I need to copy two files now instead of one, where all I want is to have some development services, which could be living in a non-changeable file in core.

The example file could still be there, but do we really need to make the copying mandatory?

#39: Thanks for the clarification. I agree with that, I also raised that concern in #31.

You're suggesting to reduce the work to copying one file (example.settings.local.php), and letting that file refer to /sites/example.settings.local.yml? I'd be fine with that.

What do others think?

I think I would leave the example file, but provide a development.services.yml file somewhere in core/ that can be referenced always.

Not sure its a good idea to reference to a example file ...

Prefer it this way as well.

Yes, much better! Thanks, damiankloip :) I'm glad #33 didn't get committed — #43 makes much more sense.

+1, was just going to RTBC. The end result is great, the only thing I can think to suggest is to move the line declaring the container yml closer to the line disabling the render cache but that's very minor.

Committed/pushed to 8.x, thanks!

Updated the change notice at https://www.drupal.org/node/2259531 to list the DX improvements added here.

I warned in #31:

One downside of this patch is that you'll have to copy and rename *two* files instead of one. But it seems like everybody is okay with that, because it'll give us a cleaner container.

Consequently, we now have #2348219: You have requested a non-existent service "cache.backend.null".

Updated the title to reflect what was actually added -- this kept tripping me up when I saw this issue linked in other issues and in the CR.

Any thoughts on this one? #2723261: Ignore local development files in example.gitignore