Php 8.0 eol and doesn’t work beyond

[Mat-Moo]

Given that Php 8.0 is now eol, and this project doesn’t work with 8.1 is there anything happening with this project now? I saw a new maintainer was asked for, nothing happened and Kudos to @withinboredom for getting so far, but I don’t want to waste time and effort on dapr if this will be retired etc.

So what’s the plans for this Php SDK for dapr? Or do I look for another solution

[withinboredom]

Interesting. I can def update this SDK to support 8.1+ and wasn't aware it was so broken as I haven't gotten any reports. I'm working on a major update (specifically for workflows), so I will see what I can backport to this version.

[Mat-Moo]

What’s the eta? Workflows are the next thing I wanted to look at, for now trying to bump estate to 8.3 and need Kafka/service bus comms

[ariddlestone]

This would be great. I work with Mat, and we're hoping that Dapr will let us use a number of cloud services more easily in various PHP containers.

The error I'm getting installing with composer require dapr/php-sdk in a php:8.3 container is:

  Problem 1
    - dapr/php-sdk[v1.0.0, ..., v1.2.0] require laminas/laminas-httphandlerrunner ^1.3 -> satisfiable by laminas/laminas-httphandlerrunner[1.3.0, 1.4.0, 1.5.0].
    - laminas/laminas-httphandlerrunner[1.3.0, ..., 1.4.0] require php ^7.3 || ~8.0.0 -> your php version (8.3.11) does not satisfy that requirement.
    - laminas/laminas-httphandlerrunner 1.5.0 requires php ^7.3 || ~8.0.0 || ~8.1.0 -> your php version (8.3.11) does not satisfy that requirement.
    - Root composer.json requires dapr/php-sdk * -> satisfiable by dapr/php-sdk[v1.0.0, ..., v1.2.0].

When I cloned the library itself to try updating dependencies and running tests, composer install gave a number of other issues from the composer.lock file:

  Problem 1
    - laminas/laminas-httphandlerrunner is locked to version 1.5.0 and an update of this package was not requested.
    - laminas/laminas-httphandlerrunner 1.5.0 requires php ^7.3 || ~8.0.0 || ~8.1.0 -> your php version (8.3.11) does not satisfy that requirement.
  Problem 2
    - laminas/laminas-zendframework-bridge is locked to version 1.5.0 and an update of this package was not requested.
    - laminas/laminas-zendframework-bridge 1.5.0 requires php >=7.4, <8.2 -> your php version (8.3.11) does not satisfy that requirement.
  Problem 3
    - nette/php-generator is locked to version v3.6.6 and an update of this package was not requested.
    - nette/php-generator v3.6.6 requires php >=7.2 <8.2 -> your php version (8.3.11) does not satisfy that requirement.
  Problem 4
    - nette/utils is locked to version v3.2.7 and an update of this package was not requested.
    - nette/utils v3.2.7 requires php >=7.2 <8.2 -> your php version (8.3.11) does not satisfy that requirement.
  Problem 5
    - phpspec/prophecy is locked to version v1.15.0 and an update of this package was not requested.
    - phpspec/prophecy v1.15.0 requires php ^7.2 || ~8.0, <8.2 -> your php version (8.3.11) does not satisfy that requirement.
  Problem 6
    - phpspec/prophecy v1.15.0 requires php ^7.2 || ~8.0, <8.2 -> your php version (8.3.11) does not satisfy that requirement.
    - phpunit/phpunit 9.5.16 requires phpspec/prophecy ^1.12.1 -> satisfiable by phpspec/prophecy[v1.15.0].
    - phpunit/phpunit is locked to version 9.5.16 and an update of this package was not requested.

Most of these seem like they can be fixed with composer update, but the laminas/laminas-httphandlerrunner version still needs looking at.

Having said that, composer update --ignore-platform-reqs in a php:8.3 container has resulted in a build where all the unit tests pass...

Haven't tried the integration tests.

Hoping updating this won't be too much trouble 🤞

[withinboredom]

What’s the eta? Workflows are the next thing I wanted to look at

No ETA for this yet, but it is something I've been diligently working on because I want it too. Currently, I'm using a workflow library that I built before Dapr had it (https://github.com/bottledcode/durable-php) and I am working on replacing the runtime with Dapr instead of a bespoke implementation + NATS and combining it here. This will effectively make durable-php v3 and php-sdk v2 the exact same implementation.

Having said that, composer update --ignore-platform-reqs in a php:8.3 container has resulted in a build where all the unit tests pass...

I'd imagine all tests should pass. This part of the dapr api hasn't changed much (if at all). Updating the integration tests will be a pita, but doable.

Hoping updating this won't be too much trouble

Probably pretty easy. Those look like test dependencies and some stuff for if you aren't integrating with an existing project (i.e., using it in a 'standalone' mode).

[Mat-Moo]

The durable stuff is interesting concept! At the moment we just want to use a azure service bus queue, and looking at options - hence DAPR, but the eco system also has some very interesting things that could help with more RAD which is a good thing

[withinboredom]

So, just to keep you updated. The main issue with >8.1 is readonly, and with 8.4 including property hooks and aviz, this gets complicated when it comes to serialization: https://externals.io/message/125740 and https://externals.io/message/125772. Ie, how serialization works pre-8.4 and post-8.4 won't be compatible.

I'm still working out the details but I'm going to make a jump directly for PHP 8.1 and 8.4 support, so there likely won't be a release until 8.4 is released in November as I will need to support both ways of handling asymmetric visibility and the 8.4 way is still being discussed to some degree.