Closed fritzmg closed 3 years ago
Unfortunately, there's no way to fix this for me in the Composer Resolver Cloud for the moment. I need a way to be able to completely replace the PlatformRepository
. See https://github.com/composer/composer/pull/9662.
As a quick fix, couldn't you just disable ext-sodium
? Or is this PHP extension required to run the cloud?
It's shipped with PHP. You would need to unbundle it which makes no sense whatsoever.
I see. Whether it's compiled with PHP or not is probably OS related then. In the affected installations PHP was probably compiled without --with-sodium
.
This problem also affects regular deployments without the cloud. If your composer.lock
was generated in an environment where ext-sodium
was available, it will of course fail if that is deployed on a production environment, where ext-sodium
happens to be not available.
Of course. I will be able to fix it now that my PR has been merged into Composer. It will require the whole infrastructure to switch to Composer 2.0 and more work though. Might take another week or so to fix this issue.
This will be fixed in the next version of Contao Manager and the pending update to Composer Resolver Cloud 3 (https://composer-resolver-cloud.statuspage.io/incidents/kn4y3slwtl63)
As mentioned in Slack, any composer update or Contao installation using the Cloud Resolver currently fails on environments where
ext-sodium
is not available.lcobucci/jwt
(required by Contao in version^3.0 || ^4.0
; also required in the same way byscheb/2fa-trusted-device
) in version4.1.0
, which was released a few days ago, now requiresext-sodium
. The Cloud Resolver has this PHP extension available and thus the resolved set of dependencies includeslcobucci/jwt: 4.1.0
. However, the subsequentcomposer install
operation will then fail if that extension is missing:I suppose the Cloud Resolver should only enable the absolute minimum of PHP extensions, so that any additional PHP extension that is available on the client side can be defined via the
platform
configuration.