> On Mar 23, 2020, at 8:01 AM, Rowan Tommins <rowan.coll...@gmail.com> wrote: > > On Mon, 23 Mar 2020 at 09:31, Mike Schinkel <m...@newclarity.net> wrote: > >> Assuming those 6 are all the PECL packages used, then that represents 1.5% >> of available PECL packages, given there are currently 398 packages on PECL. >> >> Or said another way, there are 392 of 398 PECL packages that are >> unavailable when hosting on this managed host. > > I think that's a pretty meaningless statistic. It's like comparing how many > types of saucepan there are in your kitchen with how many are on sale, and > saying "99% of saucepans are unavailable in my kitchen". > > The crucial point is that the host doesn't have a policy of only installing > extensions which are bundled with PHP.
My "meaningless" statistic was trying to make the point in a less direct way than I am doing now that your points about hosts installing a few PECL extensions are meaningless to the original point of this thread. The original point of this thread was to make the case that PECL extensions are _not_ a viable alternative to including features in core. It does not matter if a host installs _some_ unbundled PECL extensions. What matters is that the userland developer _cannot_choose_ to use a PECL extension if the managed host does not _already_ have it installed. And if a developer cannot choose a PECL extension, then it is a flawed argument that putting features into PECL vs. core is a viable alternative because putting them in PECL ensures many PHP developers will _never_ have access to them. You also brought up some orthogonal facts about extensions being bundled vs. unbundled extensions and how a managed host might choose to install some unbundled extensions. But while your points are true, there were irrelevant to the problems identified by this thread so mentioning them in essence hijacked this thread and refocused it on concerns unrelated to the original concern of this thread. >> And any newly added PECL packages are most likely to be in that >> unavailable category > > Firstly, I'm not sure that's a reliable assumption - the package will be > made available if there is demand for it, just like the (at least) 6 > non-bundled extensions already enabled. It is a *very* reliable assumption because status-quo at managed hosting companies is by far the default. Once a managed host has a working platform they are loath to change it because something might break and create dogged wntime for their customers that is potentially devastating for their business. Thus managed hosts rarely add things to their platform unless they need them to support their platform (like redis or new relic) or there is OVERWHELMING DEMAND in userland for adding them. So it is_literal() came out in a PECL extension and I went to a managed host and asked to use it they would politely tell me "sorry, we don't support that." > Secondly, there's an implicit opposite assumption: that any newly added > *bundled* extension *will* be available. I don't think that's a reliable > assumption either, because it may still be disabled by default in whatever > underlying package the host is building from. And here again status-quo is by far the default. Distros are not going to add potentially buggy extensions to their distros. They are going to wait until an extension has had plenty of time to mature _and_ that there is a significant number of developers that want the functionality. And distro maintainers are no easier to lobby to get PHP extensions included than the PHP community is to get features in core, and there are so many more than one you need to lobby. At least with PHP we are here and can lobby once, instead of having to go to many different organizations and/or maintainers/communities and lobby individually for each. > Ultimately, the barrier to having *any* functionality included on a managed > platform like that is convincing the host that it will make their platform > better. That is a false assertion. Managed hosts will upgrade to the latest version of PHP once the initial bugs are worked out. Full stop. > If there was a stable taint extension, and WordPress used it if it > was installed, you could lobby WordPress hosts to enable it, regardless of > whether it was bundled or in PECL. Theoretically I or someone else *could* lobby hosts to include that. But that is often harder to get them to change their platform than it is getting functionality added to PHP core itself — which I say rhetorically — and this lobbying has to be done on a host-by-host basis. IOW, lobbying managed hosts to change their platform is generally a fool's errand. > Note that bundled status makes even less difference to userland: And since the original message in this thread was about userland's access to PECL on a managed host, bringing up the distinction of bundled vs. unbundled was an orthogonal distraction. Or said another way, you made a distinction without a difference regarding the concerns of this thread. > portable applications need to gracefully handle it not being there > anyway. For example, a lot of code will detect if ext/curl is enabled, > and try to fall back to URLs in file_get_contents and friends if not. Yes, when an extension is missing developers have to deal with it. Which is exactly the point. If a feature is useful to a broad range of PHP developer then choosing to put it in PECL instead of in core means that many PHP will never be able to access it and will have to each write a workaround — if possible — or just do without the feature entirely. IOW, putting in PECL creates PHP "haves" and PHP "have nots." Said another way, PECL extensions balkanize PHP and create hundreds of different flavors of PHP that have to be dealt with individually by each developer or at least each framework/CMS. Which is ironically something that people on this list have argued strenuously against when the topic of declare()s and editions have been discussed. -Mike P.S. Which is (I think) why Ben brought up the idea of a userland-controllable extension mechanism and why I followed up with a proposal to suggest PHP add support for allowing userland to load and run WASM packages. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
