Hello everybody, is there a recommended way pulling plugins as a dependency to another module when t

UPWG9AYH2

Hello everybody,
is there a recommended way pulling plugins as a dependency to another module when the plugin itself has dependencies? I want to use that code of this plugin in my own module. Usually, the plugin has no dependencies at all (no constructor params), but now i hit encounter a spryker plugin that has DI params which is a new situation to me … any ideas how to deal with it? 🤔 the class is the spryker yves CustomerAuthenticationFailureHandler.
Best

UKJND3A3H

I’d say Plugins should not be considered as Services you should deal with DI

UKJND3A3H

Plugins from a conceptual point of view are a layer for more dynamic “DI” wiring in a way?

UKJND3A3H

That does not solve your issue here though, I guess 😁

UPWG9AYH2

Hi Andreas. That means, the plugins dependecies itself should also be defined as a dependency in the DI of the module the plugin is pulled to?

UKJND3A3H

Plugins, PluginStack, etc though are often residing in PyZ for a reason. To be explicitly managed, I’d say

UKJND3A3H

Wait, it’s not directly a plugin, but a handler class, residing in a Plugin namespace 🤔

UPWG9AYH2

That was also my feeling … not really a plugin

UPWG9AYH2

At least not in the sense of sprykers “use it in other modules” approach^^

UKJND3A3H

yep. meaning nope 🙂

UKJND3A3H

But you need to get access to that service instance to inject it somewhere for sure?

UPWG9AYH2

I wrote a new authenticator but moved to another module for that … the authenticator should handle success and errors as before so the idea was to use the handler-plugins in my module … but thats not possible with this dependency … i think ill move from the new module back in the origin modules space so i can instantiate the handlers via the factories … might not be the best solution but less stressfull i guess^^

UKJND3A3H

oooor you implement your own \Symfony\Component\Security\Http\Authentication\AuthenticationFailureHandlerInterface 🤔

UPWG9AYH2

Yeah … just want to avoid a copycat/code duplication^^

UKJND3A3H

Or go with the approach you initially thought about. Pulling in the dependencies for the handler and instantiate it within your module. A bit of tech smell, but that’s probably for all the options you have

UKJND3A3H

Well, what would be the worst impact of that?

UKJND3A3H

The handler isn’t doing as much

UPWG9AYH2

I think the cleanest option would be to stick to the origin module with my new authenticator as long as there is no need to separate it as a module that can be used in other projects … for the moment there isnt such a requirement … but perspectively it would be nice to have a clean dependency on that and just add a composer dep for that

UPWG9AYH2

Or go with the approach you initially thought about. Pulling in the dependencies for the handler and instantiate it within your module. A bit of tech smell, but that’s probably for all the options you have

The thing is, the DI itself would be a dependency .. in this case the messenger … so if i would it also add to the dependency provider as well, i think there is a smell since there is the chance that the dep is not loaded yet

UKJND3A3H

Not sure if I can fully follow. Making the feature you worked on a standalone module, having a dependency to that auth handler sounds like a risk though, yes.

UPWG9AYH2

Yeah but a clearly defined one^^i mean its always a tradeoff … if i don’t want to re-implement a feature that already behaves as i want, i get some kind of dependency to it … i think thats the price^^

UKJND3A3H

yep 🙂