laminas-servicemanager
laminas-servicemanager copied to clipboard
Update psr/container
Feature Request
Q | A |
---|---|
New Feature | yes |
RFC | yes/no |
BC Break | yes/no |
Summary
Hi, is it possible to upgrade to psr/container
version 2?
See https://github.com/laminas/laminas-servicemanager/issues/18#issuecomment-879182790
Yah, I dont think we can bump to new PSR major without replacing interop container. Having interop container replaced needs a ton of work which is not yet achievable.
Maybe we can create some kind of roadmap on how we want to proceed. We need all components which are affected (which are plenty), we might need to find the most popular 3rd party components to push details to them on how to upgrade (if we want to do so), then we need to determine what kind of change/ we have to do and due to the fact that laminas always has a lack of using final
we have to bump all of these components to new majors as well.
Just spitballing, but container-interop could be polyfilled, meanwhile, for compat.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On Thu, Jul 22, 2021 at 6:23 PM Maximilian Bösing @.***> wrote:
Yah, I dont think we can bump to new PSR major without replacing interop container. Having interop container replaced needs a ton of work which is not yet achievable.
Maybe we can create some kind of roadmap on how we want to proceed. We need all components which are affected (which are plenty), we might need to find the most popular 3rd party components to push details to them on how to upgrade (if we want to do so), then we need to determine what kind of change/ we have to do and due to the fact that laminas always has a lack of using final we have to bump all of these components to new majors as well.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/laminas/laminas-servicemanager/issues/92#issuecomment-885045157, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABFVEGOKEKEFMT5DPXZHK3TZBAYPANCNFSM5A2EWVCA .
Polyfilling while changing majors sounds too hacky tbh.
Even tho, by adding return typehints to ContainerInterface::has
implementing classes would be a BC break as well. Or did I missunderstood your message?
@boesing The idea is one I put forward a while back, but I think I may have run into an issue; need to review my notes.
The idea is this:
- Inline the container-interop interfaces into this package.
- Place a "replace" entry in the package indicating it replaces those interfaces (which means that any package or app installing laminas-servicemanager will no longer pull the original container-interop package, and any update operations to this new laminas-servicemanager version will remove any previously installed container-interop package).
This then removes the need to install the container-interop package, while retaining BC for the current set of releases.
We would still need to do a new major to fully remove them and replace them with the PSR-11 interfaces, but at least our users would stop receiving the warnings.
Again, I need to review my notes and see what issues I ran into.
@weierophinney So inlining the interfaces without changes just to avoid the "abandoned" message from composer? Or what would be the goal?
Yes - that's the idea.
The problem we have currently is that all of the various FactoryInterface, AbstractFactoryInterface, DelegatorFactoryInterface, AbstractPluginManager, etc. all typehint on container-interop, which is what would require the major version bump. Most users do not directly extend those (many of the interfaces can use vanilla callables), so the primary concern is seeing that "container-interop is abandoned" message when they perform installs.
The other option is we do like we did going from v2 to v3, and create a separate set of interfaces that developers can opt-in to during v3 that typehint against PSR-11; with v4, we remove the old interfaces and only go forward with the new ones. The problem is, we've already done that once, so figuring out where they should live becomes more difficult.
The point @Ocramius makes is that we can address the concerns from the vocal majority quickly, and then buy time to do a proper migration later.
I have the same case with the message "container-interop is abandoned" on multiple projects on install/update the composer dependencies.
@dmetzler1988 yeah, can be safely ignored, and as you can see, we're working on it
Hey folks, as part of refactoring two packages, I need to refactor laminas-servicemanager to depend on psr/container 2.0. After reading this thread, I'd happily do the work to implement a PR, but I'll need some guidance to do so. If someone's up for that, I'm up to get it done. I think laminas-servicemanager is one of about 5 packages that I need to touch.
@settermjd please see open PRs
Right you are. Sorry for not checking those before posting.
No worries, just pointing you there: #96 is probably the most relevant one.
I am using the laminas-feed package for generating feeds in a TYPO3 extension. The laminas-feed package depends on laminas-servicemanager. Now the upcoming TYPO3 version requires psr/container in version 2 which conflicts with this package requirement of psr/container. So, is there a foresight when this package will be compatible with psr/container v2? By now, I only have the choice to abandon the usage of laminas-feed and look out for another package or postpone the compatibility with the next TYPO3 release in my extension.
I'd say that we need to release a new major for that: no way around it, IMO.
That could also be the only BC break, TBH.
Will a major verison will be released any time soon? Some packages already require psr2 and stuck unupdated. You can't marinade it forever...
Will a major verison will be released any time soon?
It's in progress. We discussed a plan of action during the last steering committee meeting, and @boesing is leading the effort. It will take a while to roll out, but this package will be the first, while the MVC and likely Mezzio will be last to get support (we have to ensure all the various packages on which they depend that ALSO depend on this package are released first).
You'll see some progress on this in the coming weeks.
Closed by #188