Re/forming a Working Group

[mindplay-dk]

Issue description

hey folks,

as you may have seen, I've been trying to revive the Service Providers PSR proposal.

I have thoroughly reviewed past discussions, issues, and contributions related to the Service Providers PSR proposal. I've been thinking about this project daily for about two months now. A draft PSR and meta document have been prepared based on the valuable insights gathered from the community over the years. The project is alive and well in my head again, if perhaps currently just in my head. 😅

I'm reaching out to you, the original participants who were actively involved in the Service Providers PSR discussions to understand their current level of interest and participation. if I missed anyone, please give them a mention.

If you were part of the original working group and are still interested in contributing, I would love to hear from you.
Reply to this message, let me know if you are willing to actively participate in the revival of this PSR.

I don't know if we were ever formally a Working Group in PSR terms? either way, members of this Github project have been dormant for so long, I would suggest the next goal should be to formally re-form a Working Group dedicated to the development and refinement of the PSR. This re-formed working group would actively contribute to moving the proposal through the stages of the PSR workflow - starting with the draft stage, which I'd say we're just about ready for now.

I'd be willing to take on the role of "sponsor", facilitating the progress of the PSR proposal through the workflow. I've contributed, but never formally sponsored a PSR - but to my understanding, the sponsor ensures coordination, calls for votes at appropriate stages, and tries to follow the PHP-FIG procedures, etc. I can do that, if you'd like me to?

as said, I'm not aware of any formal Working Group formation ever taking place? but I don't want to step on anybody's toes! if one of you is/was already the "sponsor" and still wants to be, I am completely fine with that as well! I'm not trying to bud in and take the lead on this, unless you want me to. I'm happy to help in whatever way I can. 🙂

but I think, first off, let's reaffirm who wants to be members of the Working Group? If you are still interested in contributing, please reply and let me know - let's put this information in the README and make it "official". If you don't reply, I think it's reasonable we assume you're no longer interested.

After that, if no one objects, I'd like to do an open call for more members to join.

I would love to have your insights and contributions for this effort, but I don't want to presume - so rather than offering an opt-out, I'm calling for you to opt back in. It's been 7 years - no saying whether any of your are still interested or have the time. 🙂

CC in no particular order, just some folks who contributed more recently, plus everyone currently a member of the Github project: @jeremeamia @Ocramius @mnapoli @moufmouf @prisis @Biont @gbprod @XedinUnknown

cheers 🙂

[Ocramius]

Unable to follow this through FIG's PSR process, mostly because it drains my will to exist.

Ping me on actual interface code reviews though: gladly providing my input there 👍

[mnapoli]

My personal stance is:

• I'd love for this to happen
• but this should not happen unless Laravel and Symfony participate (to ensure the PSR gets adopted)

That's why at this point I wouldn't support an effort without them. Happy to revisit if the situation changes.

[shochdoerfer]

I currently don't have the mental capacity to drive this forward in a way that I think is suitable for the broader PHP ecosystem.

[moufmouf]

Hey @mindplay-dk ,

First of all, thanks for reviving this. I still believe this is the single most useful thing that could happen to the PHP ecosystem.

When I last tried to advance this PSR, both Laravel and Symfony were reluctant (actually, reluctant to any PSR).
On the Laravel side particularly, it is really hard to have any kind of feedback. On the Symfony side, I've had many discussions with Nicolas Grekas at the time so you have better chances there, but their DI container is also the most evolved and the hardest to work with. Anyway, the PSR should absolutely be tailored to work properly with both, and you should not expect them to be too proactive. I also remember Nicolas Grekas saying something about standardizing factories, so that's why I reacted positively to your suggested idea of simply tagging factories with a "#[Factory]" attribute.

As for me, I'm really lacking the time to get involved right now. I need to dedicate 100% of my time to WorkAdventure, which is mostly written in Typescript. As much as I would like this to appear, I don't have the time to participate actively in a working group right now. I'll be happy, just like @Ocramius to do some code reviews and give some feedback though!

[mindplay-dk]

So what you're saying is, the PSR can't happen without Laravel and Symfony - but don't expect Laravel or Symfony to participate, in fact, expect them to be opposed?

I mean, yeah, that does kinda sound like Mission Impossible or Catch 22, doesn't it. 😅

[mnapoli]

the PSR can't happen without Laravel and Symfony - but don't expect Laravel or Symfony to participate

To be fair, we kind of did that with PSR-11. And most of the discussion was IIRC about an exception or two. Both frameworks could implement the interface on day 1 without any impact.

Our initial work with this service-provider proposal was in the same spirit.

So what I said was kind of wrong:

but this should not happen unless Laravel and Symfony participate

It's more that it shouldn't happen (IMO) without (guaranteed) Laravel and Symfony support.

If they won't do the work (which is perfectly fine), you (I mean the person carrying this PSR) would have to do the work. I think @moufmouf and I are aligned that it's not required they do it, but the PSR has to show and prove that Laravel and Symfony would be supported out of the box, without impact for them.

[mindplay-dk]

It's more that it shouldn't happen (IMO) without (guaranteed) Laravel and Symfony support.

If they won't do the work (which is perfectly fine), you (I mean the person carrying this PSR) would have to do the work. I think @moufmouf and I are aligned that it's not required they do it, but the PSR has to show and prove that Laravel and Symfony would be supported out of the box, without impact for them.

I still don't completely follow, are you saying the PSR must have first-party support?

Or just that it needs to work with those frameworks?

Because, I mean, yes, it should work with all major frameworks - but we're not really in any position to demand first-party support, that's kind of up to them, I think?

But yes, demonstrating that it's going to work with major frameworks, that's probably a must - it's hard to claim this is about interoperability if it doesn't work with major frameworks. 🙂

[moufmouf]

But yes, demonstrating that it's going to work with major frameworks, that's probably a must - it's hard to claim this is about interoperability if it doesn't work with major frameworks. 🙂

Exactly. Which means we need to have an implementation of some kind of adapter for every framework (that can afterwards be added in the core by the maintainers).

The hardest part IMO is to design a PSR that will have a performance on-par with native bundles in the special case of Symfony. They put so much energy in optimizing their container. The PSR should be crafted to not break those optimizations. Otherwise, you risk a rejection from Symfony.