What is the solution to part with this package in ZF3 (but is it necessary) ?
myserver# composer info container-interop/container-interop
name : container-interop/container-interop
descrip. : Promoting the interoperability of container objects (DIC, SL, etc.)
versions : * 1.2.0
type : library
source : [git] https://github.com/container-interop/container-interop.git 79cbf1341c22ec75643d841642dd5d6acd83bdb8
names : container-interop/container-interop
Attention: This package is abandoned and no longer maintained. The author suggests using the psr/container package instead.
zend-servicemanager adopted container-interop in its version 3 release, which happened before PSR-11 was completed. Unfortunately, that means that for this major version lifecycle, we cannot switch to the PSR-11 interfaces, as it would break backwards compatibility (due to differing inheritance trees).
I’m well aware of the deprecation of the container-interop package; I was one of the ones who voted to do that. Abandonment does not mean uninstallable, however, and we’ll have to rely on that until we can do a new major version. This will likely be sometime early next year, after the Laminas launch.
In the meantime, you can continue using the code, and ignore the warning.
Thank you very much, it’s perfect.
On this topic, I am also curious about zend-servicemanager.
It has adopted both psr/container (also in v3) and the now abandoned container-interop/container-interop which use compatible (though not via signature).
How come it uses both container interfaces? And since it does, wouldn’t it be possible to simply make interop a suggested addition (so as not to break BC) so that those projects that specifically need it can make it a hard requirement, freeing everyone else to move on ?
It uses both interfaces because usage of container-interop predates our usage of PSR-11; we were tracking the spec while it was still in development, and released version 3 before PSR-11 was ratified.
And no, we can’t just have it remove the container-interop dependency. Why? Because we use it in typehints. As an example, the
InvokableFactory all typehint against it in their
__invoke() methods, among other usage. If we were to remove container-interop from the component, any code implementing those interfaces or extending those classes would break, due to the typehint change. As such, we cannot crop the dependency until we do a new major version; if we do, we’d also need to provide tooling to help people update their own code. This is not a minor undertaking, and with the Laminas transition, we’ve had to postpone it. Once the transition is complete, we’ll be creating a list of projects like these and prioritizing them.
Mind that the current code in container-interop simply extends the preferred code found in psr/container. In that respect psr/container is actually doing the job container/interop did before that project was abandoned. That yellow warning when running a composer update is a bit annoying, but my conclusion after looking at the code is that the message can be ignored. Everything has been taken care of with elegance…