Can you explain the use case for that change?

The matcher configuration was added at a time where we thought that having the profiler in production could make sense (and so being able to enable it conditionally made sense). That's not the case anymore. Nobody should ever enable it in production.

With that in mind, I would go in the other direction and remove the matcher config altogether for Symfony 4.0 (deprecating it in 3.4 first of course).

We use it on a system where we have multiple (manual) test- and qa-applications on one machine. Both qa- and test-systems work with the same settings only the test systems have the profiler enabled to make it easier for manual testers to get to error logs and enable feature toggles that we added to the profiler bar. On the qa-hosts the profiler should not run, but only on the test-hosts. The easiest way to separate them is by host-name. Otherwise we would have to create a more complex build matrix which we wanted to avoid.

@dbrumann a quick idea: maybe you could execute something like echo "\n\nframework:\nprofiler:\nenabled: true" >> app/config/config.yml in some build script to fully enable the profiler only in some hosts ... or maybe you can use an ExpressionLanguage expression to enable it conditionally?

There are definitely other ways around it. Right now we are using a customer MatcherListener that basically does what I did in this PR, so I'm good for now. I just figured since other parts are configurable, this should be too. I'm not sure if agree about removing the matcher configuration altogether as I often use it in "pseudo-prod" instances.

With per-host env vars, you should be able to achieve the same, isn't it?