Design document for PIE based on various discussions

[asgrim]

Design outline for the new PECL replacement tool

[iluuu1994]

Is it fair to say that Packagist is used almost exclusively as a registry (i.e. extension name -> repository map)? Do we know of any extension dependencies that are complex (e.g. multiple levels of dependencies)? I'd imagine that extensions depend almost exclusively on libraries rather than extensions, which get checked during ./configure. Re-using composer sounds a bit overkill (although I'm not familiar with internals and as such can't really tell how involved that is).

[asgrim]

@iluuu1994

Is it fair to say that Packagist is used almost exclusively as a registry (i.e. extension name -> repository map)? Do we know of any extension dependencies that are complex? I'd imagine that most extension depend almost exclusively on libraries rather than extensions, which get checked during ./configure. Re-using composer sounds a bit overkill (although I'm not familiar with internals and as such can't really tell how involved that is).

Yes that's fair to say, and some context around that: during the original design doc that Derick put together, there was a number of things that ended up being "this is only possible with a registry of sorts". Since the goal is to eliminate pecl.php.net, Packagist makes a lot of sense to use. Largely, the actual require for an ext/module would be just php, and very rarely another ext (I think only one example was mentioned, can't remember which one). The thought of rolling library dependencies into this as well was mentioned, but the number of platforms makes that quite a difficult undertaking, so we'll leave that to ./configure for now indeed. The original proposal from Derick was using a "similar" format to composer.json, however, after discussing with the Composer/Packagist team, they would rather we use composer.json directly and use a new php-ext key (as per this WIP proposal)

[iluuu1994]

Thank you for your explanation. I was mostly wondering whether it may be possible to just move the index to the main repositories master branch, and then pull that. I understand that that's another dependency to GitHub (which Derick isn't fond of), although this is a very "soft" dependency (i.e. easily adjustable if the repository ever moved).

Edit: Ah, I presume it's slightly more than what I wrote above, it probably also includes extension versions, which would not be practical to manage manually, which is what I meant above.

If you tell me that the effort of something like that isn't significantly smaller than using Packagist, then I'm perfectly happy with Packagist.

[derickr]

I was mostly wondering whether it may be possible to just move the index to the main repositories master branch, and then pull that.

That's what my initial suggestion also was, but then when we spoke about it, it turned out not to be the best way forwards. Having a registry with versions, and which extension version matches with which PHP version is making things less complicated.

[derickr]

Gherkin is already a thing: https://github.com/Behat/Gherkin

[derickr]

On 25 February 2024 19:36:59 GMT-05:00, Shivam Mathur @.***> wrote:

@shivammathur commented on this pull request.

+ +All options specified in the config section of the composer.json file can also be given, including a value if they +take them. For example, for Xdebug you could run pie install xdebug --without-xdebug-compression. + +## Extension maintainer: register a PIE package + +Create a composer.json in your repository, commit: + +```json +{

• "name": "ext-xdebug",
• "type": "php-ext-zend",
• "license": "Xdebug-1.03",
• "description": "Xdebug is an amazing tool...",
• "require": {
• "ext-zlib": "*",

@asgrim

Should this not be zlib instead of ext-zlib as it is a library? For extensions as dependency we can use the ext prefix, for example in phalcon, we will have ext-psr as dependency.

This was an example. We won't have libraries in the dependencies, only extensions.

[asgrim]

Merging this as a reasonable initial design, if necessary, we can make further amendments by way of further PRs.