⚠ 🔥 Important notice regarding _*Composer*_. 🚀🚀 Composer has been upgrad

sprymiker

⚠ 🔥 Important notice regarding *Composer*. 🚀🚀

Composer has been upgraded to v2 in all Spryker docker PHP images yesterday.
To start using newest images in development environment just run docker/sdk pull && docker/sdk up.

Composer v1 is going out of support soon. Make sure your projects are compatible with Composer v2.

U01N167PSBC

Would have been nice if you guys released new tags for this ... and didn't update the old one with breaking changes

UPWG9AYH2

agree with @U01N167PSBC 🙂

s.kroll

Also agree

sprymiker

I would also agree.

However there are some things to consider:

• We already have several dimensions in tags to maintain. Adding one more is just increasing the Zoo and makes it unreliable. At the start we decided to go with mutable images to be able to provide security upgrades seamlessly for everybody. I, personally, do not see composer as a dimension.
• We were considering having switch in docker/sdk an deploy.yml. However we refused to go this way once Composer v1 depreciation notice has been published.
• Composer always was a constant, but not a variable. We always installed it without version in arguments and got single compatible version. Once version 2 came installer started to install new version without any notice (It was in Oct'20). We managed our PHP images to install concrete version 1 to wait until Composer v2 becomes mature and give everybody time to be compatible.
• Eventually github.com has changed token format and Composer stopped working with new tokens. That was like a trigger to move.
We did not expected any problems related to Composer v2 upgrade at this moment of time. As we expected that everybody are aware that Composer v1 is going out of support. Starting 1st May’21 packagist starts to slow down all downloads made by composer v1. It is time to move forward.

This situation is definitely an edge case. Such upgrades are so rare, once per a decade. The fix should be quite simple.

I will write simple steps to fix the compatibility issue. It should fit most of the projects that struggle.

sprymiker

Please, follow the following steps to make composer.lock Composer v2 compatible:

1. Install Composer v2 on your host (if not already installed)
2. run composer remove sllh/composer-versions-check --ignore-platform-reqs --no-scripts
3. run composer require spryker-sdk/phpstan-spryker:^0.3 -W --ignore-platform-reqs --no-scripts
4. If you have phantomjs-installer, run composer require jakoch/phantomjs-installer:^3.0 -W --ignore-platform-reqs --no-scripts
5. run git commit -m "Composer v2 compatibility" && git push

U01N167PSBC

Your basic reasoning why you upgraded to composer 2 is fine with me, but I look at it from an Enterprise PoV, and this particular change is for many applications a possible breaking change.

U01N167PSBC

We use for our installations a specific tag to ensure that images that worked a week ago will also work in 3 months.

U01N167PSBC

Since we presume that within one tag there will only be minor fixes or security stuff but nothing breaking.

U01N167PSBC

So indeed composer is a dimension to consider within your basic docker images, otherwise exclude composer from the image and put it in the docker compose files shipped with docker-sdk

U01N167PSBC

Look at it this way ... if this image wasn't spryker specific but a more general used one this breaking change could have bricked huge infrastructure setups for legacy applications

sprymiker

I fully agree with the statements. The vision is the same.

The expectation was that it won’t impact. Otherwise the decision could be different.

sprymiker

If anybody needs a help with compatibility fixes or a workaround, please, write to me. I am here to help.

sprymiker

As a temporary workaround previous images can be accessed via hash tag. The mapping is:

7.3-alpine3.12 spryker/php@sha256:84ccd6d38962b649b3ff349831ca3b31b090154399ec06ae1f9f35c4ca2fe30f

7.3-alpine3.11 spryker/php@sha256:1da40658d379edcf2d836b6cdda3aa1a7fe97a2f57cdd3d8faed2acbdcee0542

7.3-alpine3.10 spryker/php@sha256:3add28092e0556d236d02bd7af3f504190cb79bbd25fcab0a6d721fcb9edf57f

7.3-alpine3.9 spryker/php@sha256:343d1a549e0b0d008f50fe934b4eaa3bd3e1be2c47e2d9090b42ff376c231981

7.3-debian-buster spryker/php@sha256:b9db79b535248ea55cefb372c7ba2a8144063da1e14e2468f53dc52f9340a9b0

7.4-alpine3.12 spryker/php@sha256:7da6153c7294273f9ec59c011cc76d2c6c8ec2f0f4fbffd09b09d19dfd2ae184

7.4-alpine3.11 spryker/php@sha256:35788c571a3acb606f8f04654355d19e18d5aab499f33029670f4cac4d0e8f90

7.4-alpine3.10 spryker/php@sha256:98d3deebcc61d5575b37c14340eef493cc43ea24d423278fcc4251c14f3775a7

7.4-alpine3.12 spryker/php@sha256:7da6153c7294273f9ec59c011cc76d2c6c8ec2f0f4fbffd09b09d19dfd2ae184

7.4-debian-buster spryker/php@sha256:f6d9e57eef028a1a45c70bd4aa3c606864fa1f1fa9d52a5229783f78df7030a3

U01F7P3D9NH

I thought I screwed my complete repo... Composer comments fixed everything locally. Hope it will help on the pipeline as well 🙂