[Revert] Remove the null and memory backend definitions from core.services.yml in favour of devel module providing them instead

Yes I think we should only have things in the container we expect to be used. It's a dependency injection container, so it should be for actual dependencies, not things to keep around because you might possibly want one day - that's what self-storage container are for.

#2296457: Use container imports to reduce redundant services would let us keep the stub definitions in core without them actually being included in the runtime container, but just moving them to devel gives us a good starting point at least for developer-only services.

I think this should be doable.

Do not fully understand this task. Should I only remove 'cache.backend.null' and 'cache.backend.memory' definitions and leave actual classes (Drupal\Core\Cache\MemoryBackendFactory, Drupal\Core\Cache\NullBackendFactory) in peace?

Needs work for #8.

If we will remove
$settings['cache']['bins']['render'] = 'cache.backend.null';

then the default Drupal\Core\Cache\DatabaseBackend will be used.

That's already the case, example.settings.local.php is just an example.

Checked, there is no other instance/usages/mentions of these services.

At some point we could ship with an services.local.yml which could include this null/memory backend again.
Is there some general resistance against that?

Committed 630b08a and pushed to 8.x. Thanks!

@dawehner #2296457: Use container imports to reduce redundant services.

Hm, I don't get why you want to remove this so much :)

The enabled-by-default render cache is a serious burden if you're doing frontend development in 8.x, that specific example was the most useful part about example.settings.local.php, and now it is no longer documented anywhere *and* you need to provide two files to disable it. Yes, maybe devel will provide that as a setting, but it doesn't yet.

We have 239 services in core.services.yml, there is no way that two trivial, by default unused service definitions are going to have an even remotely measurable impact ;) And IMHO, the DX of having that was more important than "cleanliness" of core.services.yml.

That would work for me too, the only problem with that is that it would be more likely that contrib/custom modules would not be tested for that (making conditional changes in view alter/preprocess => must be considered in the cache key). And it would be harder to make sure it works if it's not enabled by default, as for tests, we would have to enable it specifically.

But, how would you do that if not by having the render cache bin default to a null backend, which would then have to exist? Another setting on the performance page after we successfully purged the block cache option from it? That would be hard to get through UX reviews.

Just noticed this was gone today, it's part of my workflow to turn off render cache so I know what I'm looking at isn't cached also for profiling twig template conversions.

We'll need to update this documentation page with the appropriate way to disable render cache.
https://www.drupal.org/node/1903374

@damiankloip What is the new way to do this now that the null bin is gone?

Once we would have support for a services-local.yml file (using imports) we could provide it inside an example file as well.

This issue has disrupted the workflows of many people. Berdir, joelpittet, tim.plunkett (mentioned in #2315613-14: Add a development.services.yml for development), myself and I'm sure others.

Why was this committed without consulting a wider group of people? This was only tagged "Novice", so it was impossible to discover. Few if any people were pinged to ask for feedback. To make it even worse, this was committed before the suggested alternative is actually available (devel module).
That's rather rude.

I'd like to see this patch reverted. It can be re-committed as part of #2315613: Add a development.services.yml for development, which would prevent breaking people's workflows.

Tagging the issue "Novice" doesn't make it less visible; also what else would you tag it with? Whose responsibility is it to ping other people? I don't think there's any rudeness; we can of course revert the change if it needs more discussion or consideration.

That said it's not novice now. ;)

xpost. :)

The alpha is scheduled for tomorrow, so if it is causing problems for people, I do think it makes sense to revert it and then include it with the other issue.

Thanks.

We were having bot issues before.

Ok, seems like this has screwed with some peoples' workflows, so not a great change to make just before an alpha. I've reverted for now, but we can keep discussing.

Committed and pushed to 8.x.

See you in #2315613: Add a development.services.yml for development.

"Rude" was a poor word choice. My apologies.

I'll help reland this as part of #2315613: Add a development.services.yml for development. I've already rerolled it (because this revert makes it so that that patch no longer applies) and included this patch in it: #2315613-31: Add a development.services.yml for development.