`ext-pdo_sqlite` is not really installable about laminas-ci-matrix-action

[Ocramius]

Totally missed this again, sorry. In practice, I ended up moving away from the laminas CI setup in https://github.com/Ocramius/event-sourcing-workshop/ for now.

That said, I think we may need an explicit map of require to PECL/APT packages here: there is no clear rule on what needs to be installed.

For instance, installing Sqlite3 + PDO means having ext-pdo_sqlite 🤷

[boesing]

I remember that I somewhere had some kind of mapping for these cases... 🤔

[boesing]

https://github.com/laminas/laminas-continuous-integration-action/blob/9376275b657d69ec7bbe72fb4b94b88e4724a42f/scripts/extensions.sh#L53

That was somehow removed but only relates to sqlsrv and not to sqlite.
Does that extension actually exist or should it be ext-sqlite instead in combination with ext-pdo?

[Ocramius]

In composer, ext-pdo_sqlite means "PDO with Sqlite driver", which is kinda weird :|

[boesing]

Mh, could you try to actually add pdo + sqlite to your .laminas-ci.json in the extensions list?
Afaik, sury provides some magic to actually deliver these via dedicated packages.

[Ocramius]

I tried adding pdo and sqlite3 (sqlite doesn't exist)

[boesing]

Does that work or is the sqlite plugin for pdo missing afterwards? 🤔

[Ocramius]

When installing sqlite3, PDO also gets PDO-Sqlite 🤷

[boesing]

That was what I was expecting.

So maybe we should add some kind of "rules" for this.
Something like:

• parse extensions with pdo_(.*)
• if exists, add pdo to the extensions list we do provide to the container
• add special handlings for sqlite (so require sqlite3)
• ignore those without special handlings

This will at least avoid the CI container from failing. Is there a list of all these pdo_* combinations?

[boesing]

It seems that this works: https://github.com/laminas/laminas-db/blob/da6d5a49ac4f200da61b3a59096bf2717fbaf928/.laminas-ci.json#L5

[Ocramius]

Consider that it's not in the required dependencies though: https://github.com/laminas/laminas-db/blob/da6d5a49ac4f200da61b3a59096bf2717fbaf928/composer.json#L33-L43

[boesing]

Correct, I just try to find solutions here.
I don't care if its the requirement of a package - if packages do not explicitly require extensions but provide some via .laminas-ci.json, that would be fine for me.

Imho, the container should convert extensions to the appropriate namings of the packages. As of now, we are lucky that sury usually names packages exactly the same as they're named in PECL. Sadly, thats not the case for those pdo_* extensions.
So we should rename it within the container like:

if (string_starts_with($extension, 'pdo_')) {
    $extension = str_replace('_', '-', $extension);
}

Do we have other ideas or should we create a bug ticket within the container action?