[RFE] unlock "pecl" vendor name

[remicollet]

Hi,

I started using the pecl vendor name, as I think it makes sense to use it for an extension existing in https://pecl.php.net/, especially when maintained by the PHP group (in https://github.com/php)

I don't really like the idea of using vendor = extension, creating tons of vendors (ex: apcu/apcu)

Sadly, now the pecl vendor is locked

So I think it will be nice to unlock this vendor to allow other extension maintainers to add more.
Perhaps another way exists and may be better.

Open for discussion

[stof]

There's already several extensions registered using the pecl vendor name. So I don't think it has any special blockage.

The common rule for vendor names still apply: you cannot register a new package under an existing vendor name if you are not part of the Packagist maintainers of one of the existing packages of that namespace.

[remicollet]

There's already several extensions registered using the pecl vendor name.

All from me :)

So I don't think it has any special blockage.

And for pecl/parallel I had to create it, and give it to realFlowControl

The common rule for vendor names still apply: you cannot register a new package under an existing vendor name if you are not part of the Packagist maintainers of one of the existing packages of that namespace.

Yes, this is the rule I propose to change, only for pecl.

[stof]

Note that removing this restriction on the vendor name would then mean that anyone can submit a pecl/* package, even for packages that are not part of the php organization on GitHub (and even packages that would not be PHP extensions at all). Is this really the expected behavior ?

[remicollet]

Is this really the expected behavior ?

I don't know, perhaps some other restriction needed (ex sources under https://github.com/php)

Of course, after adding some ext (by me for others), we'll probably have enough allowed maintainers to add more.

[derickr]

I thought we had this discussion beforehand, and decided against using pecl as a vendor, I'm certain. Maybe @asgrim has the write up?

[derickr]

Ok, seems not (https://github.com/php/pie/issues/650.

I do think we should no longer pursue the name "pecl" though. And I think I do believe having each extension has its own vendor now makes more sense, as it would allow for every maintainer to do their own thing.

[asgrim]

I disagree with unlocking the pecl/ vendor. The pecl/ vendor should really be limited to exts in the PHP GitHub org, not just open for anyone.

As a rule of thumb, any extension should use their own vendor (e.g. Datadog could use datadog/, Xdebug uses xdebug/); bear in mind it is possible for a single vendor to have multiple packages. This is the same theory as Composer uses, so IMO nothing changes in the case of PIE.

The exception to this is those exts already hosted in the PHP GitHub organisation (i.e. https://github.com/php), e.g. yaml, mcrypt, timezonedb etc.. As per php/pie#65 - we had discussed these, and in that issue and both in the PHP Foundation discussion channel, the only consensus was that php/ should not be used. Therefore I accepted it as pecl/ instead.

Once some different maintainers have been added to allowed under pecl/ vendor, I think this will be a non-issue.

[cmb69]

Given my concerns raised in ThePHPF/pie-design#27, I would appreciate to use the pecl namespace only for extensions hosted on https://github.com/php.

[Seldaek]

Yup I tend to agree that opening this to anyone is bad as the PECL name carries some implicit trust in the eyes of many.

[sebastianbergmann]

I do think we should no longer pursue the name "pecl" though.

👍

To me, what @asgrim, @cmb69, and @Seldaek wrote about, is about perception. Only extensions already hosted in the PHP GitHub organisation should be allowed to use pecl and we should strive for getting rid of the name there as well. Ultimately, I would hope for 0 extensions under the name pecl. Most importantly, though, no "random" and/or new extensions should be allowed to use that name.

[remicollet]

Sorry, but I think we need a vendor for extensions maintained by the PHP community, and pecl makes sense.

I use "remi" for extensions I've created and I maintain. I don't want to use it for adopted extensions.

[cmb69]

[…] and we should strive for getting rid of the name there as well. Ultimately, I would hope for 0 extensions under the name pecl. Most importantly, though, no "random" and/or new extensions should be allowed to use that name.

How is this supposed to work in practice? There are more than 80 extensions under https://github.com/php. Are these supposed to be moved to some other namespace in the long run? Who would do this? Which namespace? And what if php-src unbundles further extensions? So far we moved them to a repo under github.com/php; if there was a maintainer, we would likely not have unbundled the extensions. And what about abandoned extensions living elsewhere (I think that @remicollet is concerned about these)? We could move them to github.com/php, but if we can't use the "pecl" namespace for those, we're back to square one.

[Seldaek]

I think it's fine to use pecl, or php namespace for those.. But imo it shouldn't be open to anyone and we should only allow php internals members to submit new packages there, or perhaps restricting it to extensions owned by the php github org would be easier?