Allow proposed PIE extensions to be submitted to Packagist

[James Titcumb]

Something we have discussed with previously is to allow a PIE-formatted PHP extension to be submitted to Packagist.

https://github.com/ThePHPF/pie-design?tab=readme-ov-file#extension-maintainer-register-a-pie-package

The TLDR is:

• A PIE-enabled PHP extension will have a composer.json
• The name of the package would be ext-<extname> (this is forbidden at the moment, due to the naming regex)
• The type of the package would be php-ext (for a PHP module) or php-ext-zend (for a Zend Extension)
• The php-ext is a proposed new top level element in composer.json - proposed JSON schema is here for reference

Example repository containing a composer.json in this style at the moment - I will be using this to initially work on PIE:

• https://github.com/asgrim/example-pie-extension

Presently, this extension cannot be submitted, since the naming is not correct:

[James Titcumb]

Parts of this are already WIP - see composer/composer#11795

[Christophe Coevoet]

The question then is also how those PIE extension packages are treated in Packagist, as they won't make sense in the composer solver (they need to be installed with the PIE tool):

• filtering them in the pool builder (as currently done in the composer PR). Drawback: the metadata are still downloaded (maybe even repeatedly depending on how other parts are implemented) before ignoring them
• exposing those packages as a separate package repository in packagist.org (for instance at packagist.org/extensions/). This might require solving the case where different versions of a package have different types.

If vendor namespaces are not used, packagist will need to be adapted to support such extension package names (which might be ambiguous between the page of the package ext-foo and the listing of all packages in the ext-foo namespace depending on the URL structure)

[Jordi Boggiano]

Everything should be ready to submit to packagist now, I'll add an extensions list page later.

[Christophe Coevoet]

@Seldaek when I mentioned packagist.org/extensions/, I was mostly referring to the JSON files, so having a separate packagist.org/extensions/packages.json file (with the associated files for each package) for the extension repository. This way, composer would not see those packages when loading packagist.org/packages.json and PIE could load a repository containing only extensions.

[Jordi Boggiano]

Yeah I got that, I handled that in the pool builder because that way the metadata requires no change on packagist.org, which simplifies things quite a bit.

Loading the metadata doesn't matter as the only case it will happen is if someone makes an error requiring an ext with Composer, then it won't work and they will remove the extension from their composer.json.

[Jordi Boggiano]

Ok listing is up at https://packagist.org/extensions - closing this for now. We'll move further once we have more packages and usage IMO.