Closed wolfy-j closed 4 years ago
Agreed
I'm trying to pick the best approach currently. Either do it in 2.0 (will take a while) or 1.6.0. Later will cause issues for the users who use Zend indirectly... won't affect frameworks and bridges.
Maybe it's better yo just copy one of the solutions and just embed it to our repo? We will kill a lot of conflicts problems with that...
It won’t solve the problem for people with indirect decencies unfortunately. Ideally I would like to remove PSR-7 implementation from this repository completely and depend on the standard only.
It won’t solve the problem for people with indirect decencies unfortunately. Ideally I would like to remove PSR-7 implementation from this repository completely and depend on the standard only.
Can you name an example of the situation? If we copy code and change namespace to ours - no conflicts will occur.
See the example at README.md, it will stop working after removing zend dependency. :(
See the example at README.md, it will stop working after removing zend dependency. :(
Well, just release a new version and mention that it has a BC breaker. Or tell that you can manually add zend library to your deps if you want to stay with them.
IMHO, do it in 2.0
public function __construct(
Worker $worker,
ServerRequestFactoryInterface $requestFactory = null,
StreamFactoryInterface $streamFactory = null,
UploadedFileFactoryInterface $uploadsFactory = null
);
why? why don’t you give me the right to install any others PSR-7 implementations?
public function __construct(
Worker $worker,
ServerRequestFactoryInterface $requestFactory,
StreamFactoryInterface $streamFactory,
UploadedFileFactoryInterface $uploadsFactory
);
why not? i don't use no zend/diactoros
no nyholm/psr7
.
please let us decide for ourselves which PSR-7 implementations to use.
It won’t solve the problem for people with indirect decencies unfortunately. Ideally I would like to remove PSR-7 implementation from this repository completely and depend on the standard only.
please listen to yourself, you say the right thing!
It won’t solve the problem for people with indirect decencies unfortunately. Ideally I would like to remove PSR-7 implementation from this repository completely and depend on the standard only.
please listen to yourself, you say the right thing!
Well, you still can do your own implementation using just RAW client.
It won’t solve the problem for people with indirect decencies unfortunately. Ideally I would like to remove PSR-7 implementation from this repository completely and depend on the standard only.
please listen to yourself, you say the right thing!
Well, you still can do your own implementation using just RAW client.
I understand all this. I'm against it:
https://github.com/spiral/roadrunner/blob/4016bdf2d53faca43408dd28b0809a45d508d338/composer.json#L22
RR won’t include any concrete PSR-7 implementation in 2.0. This question is more about 1.*
RR won’t include any concrete PSR-7 implementation in 2.0. This question is more about 1.*
https://github.com/middlewares/utils https://github.com/middlewares/utils/blob/master/src/FactoryDiscovery.php
this implementation could help... at least 5 other implementations are listed there.
@wolfy-j What's the status on 2.0? I'd be looking to use this with Phalcon's 4.x PSR7 implementation, happy to help and/or test in any way I can
If 1.x is going to be non-breaking, then is it worth moving at all? Since Zend has 100% coverage anyway and this sounds like a solution that will be replaced by 2.0
The 2.0 lives in our minds, there a bunch of things we have to do for it: 1) upgrade Goridge to 3.0 2) implement cascade service container 3) implement proper logging convention (yes, Golang does not have anything close to PSR-3) 3) move all services 4) remove unnecessary dependencies
So it will take some time. We are currently at 1) and 2).
@wolfy-j Okay sure, that makes sense - let me know if I can help with that
The best way forward here to me seems to be to require psr/http-message-implementation
, which is a virtual package.
It's a way for packages to declare they support this and a bunch of them do (including Zend and Nyholm). This means the developer would be free to wire any implementation they see fit.
laminas/laminas-diactoros is used instead of zend dictators
Zend is now officially the Laminas project and we have to redo the dependency. This will be addressed in the next major release. Currently, we are thinking about removing Zend dependency entirely and replace it with https://github.com/Nyholm/psr7.
Note, you will experience BC break if you use Zend dependencies indirectly.