To record a discussion so far on Composer package naming.

Current plan: the Composer package name is something like ext-debug in composer.json. However, as per composer/packagist#1440, this would need specific support to be added to Packagist.

How are names decided currently?

as far as I understand it, the ext author decides the name, but then it has to be approved and added to pecl.php.net by hand; that would be done by requesting on the pecl mailing list, so if there was an objectionable name for some reason, it would be discussed prior

What about using vendor/ prefixes?

An advantage of using vendor/package format, is it allows multiple implementations; for example if I wanted to fork xdebug, and install my custom xdebug, I could do pie install asgrim/xdebug instead of pie install xdebug/xdebug to get my own fork.

This is an option, but we would still need a way to either derive or determine the extension name. Some options

• derive it from the package name, e.g. asgrim/xdebug and xdebug/xdebug both have extension name of xdebug (i.e. just remove the "vendor"). Drawback; this may make an easy way to conflict with naming, both unintentionally + intentionally
• require a name in the new php-ext section in composer.json, e.g.

  {
      "name": "asgrim/example-pie-extension",
      "type": "php-ext",
      "license": "MIT",
      "description": "Example PIE extension",
      "require": {
          "php": ">=7.1,<8.4"
      },
      "php-ext": {
          "name": "example-pie-extension",
          "priority": 74,
          "configure-options": []
      }
  }

• use provide; e.g.:

  {
      "name": "asgrim/example-pie-extension",
      "type": "php-ext",
      "license": "MIT",
      "description": "Example PIE extension",
      "require": {
          "php": ">=7.1,<8.4"
      },
      "provide": {
          "ext-example-pie-extension": "*"
      },
      "php-ext": {
          "priority": 74,
          "configure-options": []
      }
  }

  Drawback to this: what if an extension (for some reason) decides to list multiple provide (for example, it provides a psr/message implementation as well as itself being ext-my-psr-messages); especially, if it somehow provide multiple extensions? 🤯

Questions - retroactive vendor prefixes

If we do add vendor/ prefix, how will we decide vendor prefix for existing extensions? For some, it is easy where a vendor is already used by the author(s), e.g. ext-xdebug could use xdebug/xdebug, ext-datadog-trace could use datadog/datadog-trace, etc.; however, some it might be unclear; e.g. ssh2. One could assume it should become php/ssh2 but there are implications to this (since at this point, it could conceivably be that php/ is a special vendor, and may even already be reserved by Composer/Packagist, for instance (would need to check this).

General points raised

• Packagist maintainers are keen to ensure we don't enable things like dependency confusion attacks or "typo squatting" for package names