Stand alone plugin manager replacement

[gsteel]

Q	A
Documentation	not-yet
BC Break	yes
New Feature	yes
RFC	yes

Description

Further to discussion in #121, this is an initial draft (Without docs or tests) for a replacement plugin manager enabling the removal of the hard dependency on Laminas Service Manager.

The expectation is that view helpers are configured as a map of ['alias' => 'container-id-or-class-string']. An attempt is made to new class-strings not present in the container and whatever comes out needs to be callable

Questions

• would it be advantageous to allow closures|callables as values in the map?
• would it be better to return Closure and use closure from callable before returning?
• should runtime modification of the configured helpers be allowed?

[gsteel]

Paging @Ocramius and @froschdesign for review/discussion 🙏

If this looks like a feasible approach, I'll do some more work on it… It'd be great if we could get #118 merge so that CI stands a chance too :)

[boesing]

Just curious about this:

Do we plan to remove servicemanager dependency in all laminas components?

[gsteel]

I personally think that making "things" more vendor agnostic might mean that laminas-view specifically might have broader appeal. In my typical uses of the lib, I'd still be using Service Manager, but I think it's generally a good thing that all you need is any Psr-11 container wired up… I'd appreciate further discussion on whether this pull is feasible/likely to be merged - I'll put in some more effort if so.

[froschdesign]

Do we plan to remove servicemanager dependency in all laminas components?

I think we should ask @weierophinney because the idea is based on his work on laminas-feed.

[Ocramius]

Note: if we plan to get rid of plugin managers from laminas/laminas-servicemanager, then let's please not re-implement a plugin manager per-component.

That was what we had with Zend_Loader and all that stuff in the past: it's a worse solution, IMO.

Yes, having the dependency here is a pain, but the abstraction should be well defined, and @gsteel accumulated loads of experience in how to make type-safe plugin-manager abstractions.

Having a PSR-11 dependency (that provides the plugins) would certainly suffice, if well-typed, but rewriting it everywhere feels meh.

[boesing]

TBH: I would be fine if the project depends on psr/container directly.
Much more smoother upgrade path.
Having no interface at all (as in here) does not feel like an improvement tho.

[gsteel]

Is it feasible to look at AbstractPluginManager, remove its inheritance tree and make it depend on a PSR container in a final constructor? (Obvs in a major)… That way we can have plugin managers in components that only need to add the generics and perhaps validate instances on the way out rather than on the way in?

[weierophinney]

TBH: I would be fine if the project depends on psr/container directly.
Much more smoother upgrade path.

There's a pretty huge BC break if we do that, however: since the release of ZF 2.0, we've been able to provide view_helpers configuration using SM configuration semantics. If we provide a standalone PSR-11 implementation and/or switch to having it jsut consume PSR-11 without providing an implementation, we'd need to ensure there's an additional package that provides a laminas-servicemanager-backed version for use with each of Laminas MVC and Mezzio to ensure existing configuration continues to work. And we'd need to depend on that package by default until a new major, at the minimum, to prevent breakage in existing applications. Ideally, we should likely keep it for another entire major cycle to provide ample time for users to migrate.

Yes, moving to straight-up PSR-11 would be easiest in terms of upgrade path and interop, but it comes at the expense of our own ecosystem.

[gsteel]

Further to my comment, I had something like this in mind: https://gist.github.com/gsteel/eb0cff849f57bdda5aee98bfd601af66

[gsteel]

I'm killing this PR - In summary I think most feel it's lacking much advantage over the current plugin manager.

[Ocramius]

@gsteel remember to adjust milestone/labels, or else it still lands in release notes 😬

[gsteel]

Sorry @Ocramius - I'll remember next time!