Version 3.11 conflicts with ext-psr

[remicollet]

When psr extension is loaded

Fatal error: Uncaught ValueError: class_alias(): Argument #1 ($class) must be a user-defined class name, internal class name given in ......src/autoload.php:13

so class_alias cannot be used there

[remicollet]

Using old code (in src/autoload) can be a workaround

namespace Interop\Container;

interface ContainerInterface extends \Psr\Container\ContainerInterface {
}

namespace Interop\Container\Exception;

use Psr\Container\ContainerExceptionInterface as PsrContainerException;
use Psr\Container\NotFoundExceptionInterface as PsrNotFoundException;

interface ContainerException extends PsrContainerException
{
}	
interface NotFoundException extends ContainerException, PsrNotFoundException
{
}

BTW, I don't see any real benefit in replacing container-interop, user simply should switch away from it, and composer display a warning about this when installed

Package container-interop/container-interop is abandoned, you should avoid using it. Use psr/container instead.

[Ocramius]

@remicollet the reason why we did replace is for BC specifically: we wanted to be able to migrate to psr/container:^2, and we couldn't due to no movement on container-interop/container-interop.

Dropping container-interop is not viable due to the amount of downstream factories and inheritance-based designs that would just break.

On this end, I must say that I didn't know that a psr extension existed, but I'd treat the BC break against that as much smaller compared to the effect of dropping container-interop/ directly (much more problematic).

One alternative we could have is to use inheritance with the PSR interfaces, as you suggested, instead of aliasing.

[boesing]

TBH: I have no idea how to fix this.
I also don't see/understand why it is not possible to use class_alias for interfaces provided by an extension.

We also had RFC open for months, almost 1 year and there was no feedback in that direction.

That extension also is problematic when it comes to multiple major versions of the PSR standards. So until there is no dedicated extension per RFC, that extension needs to keep BC compat or a hilarious amount of versions to reflect all version combinations.

Given the fact, that there are 3 major versions for psr/cache, that extension will block any user from migrating to any newer version. Therefore, I would conflict with that extension. Sadly, we haven't done this in the X.X.0 minor release already, therefore it will install until we do conflict.

[Ocramius]

Adding "conflict": {"ext-psr": "*"} is a viable solution, for now.

[boesing]

Adding "conflict": {"ext-psr": "*"} is a viable solution, for now.

Yes, but that will only apply to the 2nd patch of the minor. So 1st patch still installable. :-/

Given the fact, that there are 3 major versions for psr/cache, that extension will block any user from migrating to any newer version.

Only for all 3 psr/cache versions + all psr/container versions, there need to be these major versions of the extension:

• one with psr/cache v1 + psr/container v1
• one with psr/cache v1 + psr/container v2
• one with psr/cache v2 + psr/container v1
• one with psr/cache v2 + psr/container v2
• one with psr/cache v3 + psr/container v1
• one with psr/cache v3 + psr/container v2

You see where this is going, right? I would not use such extension.

[Ocramius]

So 1st patch still installable. :-/

Yes, but we can't do much about that anyway. Let's just declare the conflict, since bug reports need to target the latest patch release anyway, in order to be considered: at least we declared where we stand.

[boesing]

Guess this issue reported here also covers the error "reported" in the commit:
4756d91#commitcomment-70569233

[MeetKamal]

Hello all, have added the conflict but still getting same error :(

[Ocramius]

Are you on the latest version? Check composer show --installed: you should be on 3.11.2 or newer.

[MeetKamal]

Hi @Ocramius - Just checked the version its 3.11.1
laminas/laminas-servicemanager 3.11.1 Factory-Driven Dependency Injection Container

how we can upgrade ?

[Ocramius]

By uninstalling ext-psr, for which we declared an explicit compatibility conflict 😁

[MeetKamal]

Hi @Ocramius
Thanks for the update, it seems service manager upgraded now on local.

• Upgrading laminas/laminas-servicemanager (3.11.1 => 3.11.2)

[MeetKamal]

HI @Ocramius

Now all backend command executed, and it seems project setup . but when we go to front end its showing same error on front end

Fatal error: Uncaught ValueError: class_alias(): Argument #1 ($class) must be a user-defined class name, internal class name given in /var/www/html/m245/project-community-edition/vendor/laminas/laminas-servicemanager/src/autoload.php:1

[MeetKamal]

Fatal error: Uncaught ValueError: class_alias(): Argument #1 ($class) must be a user-defined class name, internal class name given in /var/www/html/m245/project-community-edition/vendor/laminas/laminas-servicemanager/src/autoload.php:13 Stack trace: #0 /var/www/html/m245/project-community-edition/vendor/laminas/laminas-servicemanager/src/autoload.php(13): class_alias() #1 /var/www/html/m245/project-community-edition/vendor/composer/autoload_real.php(59): require('...') #2 /var/www/html/m245/project-community-edition/vendor/composer/autoload_real.php(42): composerRequired13112b11e1877c5fa97a92a7af68de2() #3 /var/www/html/m245/project-community-edition/vendor/autoload.php(12): ComposerAutoloaderInitd13112b11e1877c5fa97a92a7af68de2::getLoader() #4 /var/www/html/m245/project-community-edition/app/autoload.php(51): include('...') #5 /var/www/html/m245/project-community-edition/app/bootstrap.php(43): require_once('...') #6 /var/www/html/m245/project-community-edition/index.php(12): require('...') #7 {main} thrown in /var/www/html/m245/project-community-edition/vendor/laminas/laminas-servicemanager/src/autoload.php on line 13

[MeetKamal]

HI @Ocramius

Please review above error and guide for the same

[andrew-demb]

@MeetKamal latest versions of package is not compatible with ext-psr.
You should uninstall it from the server. Uninstalling from developer machines is not enough.

[Ocramius]

Also, only run composer install on a system that is compatible (or same) to your production environment.

[MeetKamal]

Thanks, will try on another machine. Have tried the composer install but no luck

[AkashicSeer]

Can I say I am not shocked this was never fixed. Does anything work these days at all?

[Ocramius]

@AkashikSeer we explicitly declared a conflict with ext-psr: it is up to you to either downgrade this package, or uninstall ext-psr. This issue is 100% solved from this end.

[AkashicSeer]

Sorry thanks.. I found out it was a framework I was using. I had to go all the way to the frameworks github page and clone it just so I could run composer install and upgrade because there was no friggin composer file in the download. I had tried downloading it because the composer line they gave to install it returns that it couldn't be found FFS😡 So So I eventually googled to find their repo so I could clone it to see exactly WTF was going on. I only figured it out after this. I didn't see a way in github to find past comments or whatever they call these. So, sorry.😂

…

On Sat, Aug 6, 2022 at 5:49 AM Marco Pivetta ***@***.***> wrote: @AkashikSeer we explicitly declared a conflict with ext-psr: it is up to you to either downgrade this package, or uninstall ext-psr. This issue is 100% solved from this end. — Reply to this email directly, view it on GitHub <#124 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKYQZAV35DX5II442GLJC6DVXYYLLANCNFSM5SYRHOGQ> . You are receiving this because you commented.Message ID: ***@***.***>

[ozzpy]

By uninstalling ext-psr, for which we declared an explicit compatibility conflict 😁

best solution!