Tags, Compiler Passes & Other Nerdery

Yo ahmedbhs!

Great question! My instinct was that it makes no difference, but I actually didn't know the answer to this one! Fortunately the code holds the secret - and here it is: https://github.com/symfony/...

As you can see, the "extension" class is called first on each bundle and *then* the build() method. But that doesn't make any difference. It is not until after BOTH of these that the "compiler passes" are executed, and it is a compiler pass that ultimately processes the results from registerForAutoconfiguration(). So, both spots are "early enough" and it should make zero difference :). I have seen people (and I don't disagree) sometimes skip creating an extension class entirely and instead just put things in their bundle's build() method for simplicity.

Cheers!

Hey @Boolean_Type!

cause I'm noobie in Symfony bundles/container/other stuff

Hmm, for a "noobie" you're asking some pretty good questions on some pretty advanced stuff ;).

So, you're correct that there's no way to do this directly with the tags system. And you're also correct that the user could do something crazy with a compiler pass and ContainerBuilder::removeDefinition but we don't want them to do that :).

The "tags" system is really a way to allow end-users to add more stuff to our system. In this project, we've done this but (as you know) we've also decided to always add our own KnpUWordProvider. Suppose we release the bundle like this, and for 6 months, everyone is happy. Suddenly, we get a feature request where someone wants to not include this (this exactly what you're asking for).

The fix is to make our bundle more flexible by adding more configuration. Here's how it would look:

1) Add some new option in our Configuration class so that users can have some config like this:

knpu_lorem_ipsum:
    default_provider: false

You would default this value to "true" to keep the current behavior by default.

2) Then, remove the knpu_ipsum_word_provider tag in our bundle's XML file for the KnpUWordProvider service. At this moment, the class would never have that tag.

3) In the KnpULoremIpsumExtension class, use the new default_provider config. If it IS set to true (and only if it is set to true), manually find the knpu_lorem_ipsum.knpu_word_provider service and add the tag.

That's it! So you're basically adding a new option that allows users to control whether or not this tag is there. The cool thing is that your users don't even need to understand what a "tag" is or that you're using it (unless they want to add their own custom providers). A user just sees that they can set default_provider: false to not include the default words. They don't need to care how it works internally.

Let me know if that helps!

Cheers!

Thank you so much, @weaverryan !
I've tried your proposition - it works :)

<i>knpu_lorem_ipsum.yaml:</i>

knpu_lorem_ipsum:
    min_sunshine: 10
    use_default_provider: true

<i>services.xml:</i>

...
<service id="knpu_lorem_ipsum.knpu_word_provider" class="KnpU\LoremIpsumBundle\KnpUWordProvider"/>
...

<i>KnpU\LoremIpsumBundle\DependencyInjection\Configuration:</i>

...
->booleanNode('use_default_provider')
        ->defaultTrue()
        ->info('Do you want to use the default word provider?')
        ->end()
...

<i>KnpU\LoremIpsumBundle\DependencyInjection\KnpULoremIpsumExtension::load():</i>

...
if ($config['use_default_provider']) {
         $knpuWordProviderDefinition = $container->getDefinition('knpu_lorem_ipsum.knpu_word_provider');
         $knpuWordProviderDefinition->addTag('knpu_ipsum_word_provider');
}
...

I've also tried this in KnpULoremIpsumExtension::load() instead of block above:

if ($config['use_default_provider']) {         
        $class = $knpuWordProviderDefinition->getClass();
        $container
            ->registerForAutoconfiguration($class)
            ->addTag('knpu_ipsum_word_provider')
         ;
}

But for some reason uknown for me it didn't work.

Woohoo! Nice work! You did everything perfectly.

That last block of code didn’t work only because you were... sort of doing something different.... but close. That code said “please find all services that match the class KnpUWordProvider and automatically tag them with knpu_ipsum_word_provider”. That sounds like it should work, but it will only apply to services that have “autoconfigure true”, which our bundle’s services don’t. And that’s ok and on purpose :). It’s better for our bundle to do things explicitly, which is what you did by specifically adding the tag to the service.

Cheers!

Hey ash-m!

Sorry for my slow reply!

Ok, so this entire feature is powered by "autoconfiguration". "Autoconfigure" is an option that you can set on each individual service. If "autoconfigure" is enabled for a service, then any matching "autoconfiguration rules" (i.e. the thing we add with registerForAutoconfiguration()) are applied to that service.

So, the first thing we should look at is: is autoconfiguration enabled for your services? The autoconfigure option is disabled by default on services. However, in practice, it's enabled in applications thanks to the default services.yaml file: https://github.com/symfony/recipes/blob/fb10d2ac4cf54486a1b171685f4a3d6311196938/symfony/framework-bundle/4.4/config/services.yaml#L8-L12

But if you're building a bundle, then you might have this setting. And, in general, like autowiring, the "best practice" is for bundles to not rely on autoconfiguration. Basically, if your bundle needs something to have a tag, you should configure it manually. But if you would like to make it easier for "end-users" to "auto-tag" their services (which is a good thing!), then you would call registerForAutoconfiguration(). So basically, you add this autoconfiguration rule for your end users... but then we typically don't actually rely on it in the bundle (though, there is no rule against that).

Let me know if this helps... or if i'm way off ;).

Cheers!

This helps, but doesn't explain why some services autowire and others don't. But first, to clarify, is registerForAutoConfiguration() not best practice?

Second, perhaps there is some tagging magic happening with Doctrine, but I will have an unimplemented repository interface (eg FooRepository) in my bundle and I'll use registerForAutoConfiguration() on it and the App's implementation (eg InMemoryFooRepository) will appear in the CompilerPass. But some (most*) other services do not show up until I explicitly add tags in the App's services.yaml file.

Most of these services do not have default implementations, so they're not defined in the bundle's services.xml (it's expected that the developer implement the interfaces to use the bundle). Maybe there is some relationship I don't understand between services.xml and the CompilerPass? If it's <i>better</i> to tag stuff in the App's services.yaml, I'm okay with that, but it doesn't seem to be necessary for any of the other bundles I've used.

Note: as far as my unrelated question, I decided to map all configuration variables to <b>parameters</b> in the Extension class, and then use those in the CompilerPass for the setArgument() calls. Is this okay? Is there a better way?

Hey ash-m!

But first, to clarify, is registerForAutoConfiguration() not best practice?

This absolutely IS a best-practice. This allows users of your bundle to have their service's auto-tagged. What's not a best practice is to rely on this in your own bundle. Instead, you should manually/explicitly tag your services.

but I will have an unimplemented repository interface (eg FooRepository) in my bundle and I'll use registerForAutoConfiguration() on it and the App's implementation (eg InMemoryFooRepository) will appear in the CompilerPass.

Um, hmm. I think I'll need to see some code. But also, I would run:

php bin/console debug:container the_service_id_of_a_service_that_is_not_automatically_getting_the_tag

And then see what the "Autoconfigured" option says - see if it says "yes" or "no". If it says "no", then we know that the problem is that autoconfiguration is not enabled for this service, and so that's why it isn't automatically getting the tag.

Note: as far as my unrelated question, I decided to map all configuration variables to parameters in the Extension class, and then use those in the CompilerPass for the setArgument() calls. Is this okay? Is there a better way?

Yes, this is ok... it's a great way (actually) to "store" that config so that you can read it in your compiler pass :).

Cheers!

So, just to clarify, stuff ending in Repository seem to (mostly) work as expected (except, for some reason when I inject them in listeners instead of handlers, but that probably has something to do with what's being defined in services.xml... ¯_(ツ)_/¯... ) but it looks like the problem is mostly with <i>factories</i> which I usually define next to the thing they create. So an App\Entity\ConcreteFooFactory will implement Ashm\ALib\Foo\FooFactory and of course that interface will be tagged and registered for auto-configuration in the bundle's extension class.

When I debug like you suggest (without removing the tag from services.yaml, because otherwise it breaks saying that a handler depends on a non-existent service), then it indeed shows that the class is autoconfigured <b>and</b> autowired (and of course tagged with the explicit tag).

<s>I am just now realizing that the services that fail to get tagged in the Compiler without being explicit are all in the library I abstracted (which the bundle requires).</s> (edit: actually this is inconsistent as there is also a factory interface in the bundle whose implementation requires a tag in the App... I should probably think of a way to fix that... )

To further clarify, when I say, "it doesn't show up", if I remove the tag, from services.yaml, like I mentioned, the app will crash, but if I var_dump($container->findTaggedServivceIds($tag)); die() (where $tag is the tag defined in the extension) I will see an empty array. If I leave the tag alone and var_dump, then I see the App\Entity\ConcreteFooFactory.

Any input would be great. Thank you.

Hey ash-m!

Any chance you'd be able to share some code? I could probably spot the problem, but you've got a complex enough setup that I can't quite picture it. It sounds like you are doing most everything correctly, which is why I think there may be some minor problem or minor "lost in translation" tweak that you need :).

Cheers!