Re: [PHP-DEV] Are PECL modules preferable?

This is only part of a thread. view whole thread
  109226
March 23, 2020 10:36 remi@php.net (Remi Collet)
Le 21/03/2020 à 23:52, Mike Schinkel a écrit :
>> On Mar 21, 2020, at 5:59 PM, tyson andre <tysonandre775@hotmail.com> wrote: >> FROM: Re: [PHP-DEV] [RFC] is_literal() >> >> And if it can be implemented as a PECL module, that would be more preferable to me than a core module of php. >> If it was in core, having to support that feature may limit optimizations or implementation changes that could be done in the future. > > Just wanted to address this comment which was made on another thread (I did not want to hijack that thread.) > > A large number of PHP users have no control over the platform they run on, so the option to use PECL modules is a non-starter for them.
Sorry, but PECL is the usual way for new extension - add to pecl - people start using it - if success add to php-src And later - move to pecl extensions removed from php-src Having new extension (outside of language feature) directly added to php-src is IMHO a terrible way. Having "dead" extensions in php-src is a real problem (the ones nobody take care of anymore, only adapted for new version) But I'm probably the only one who think much more extensions should be removed from php-src and maintained outside, in pecl. Remi
  109231
March 23, 2020 15:01 mike@newclarity.net (Mike Schinkel)
> On Mar 23, 2020, at 6:36 AM, Remi Collet <remi@php.net> wrote: > > Le 21/03/2020 à 23:52, Mike Schinkel a écrit : >>> On Mar 21, 2020, at 5:59 PM, tyson andre <tysonandre775@hotmail.com> wrote: >>> FROM: Re: [PHP-DEV] [RFC] is_literal() >>> >>> And if it can be implemented as a PECL module, that would be more preferable to me than a core module of php. >>> If it was in core, having to support that feature may limit optimizations or implementation changes that could be done in the future. >> >> Just wanted to address this comment which was made on another thread (I did not want to hijack that thread.) >> >> A large number of PHP users have no control over the platform they run on, so the option to use PECL modules is a non-starter for them. > > Sorry, but PECL is the usual way for new extension > > - add to pecl > - people start using it > - if success add to php-src > > And later > > - move to pecl extensions removed from php-src
Yes, it is the usual way. Which from my perspective is flawed because it means that a large population of PHP developers can never use those extensions.
> Having new extension (outside of language feature) directly added > to php-src is IMHO a terrible way. > > Having "dead" extensions in php-src is a real problem > (the ones nobody take care of anymore, only adapted for new version)
That is not the argument that was made. The argument is that a developer cannot: 1. Depend on a PECL extension to exist, and 2. Cannot even use (most) PECL extensions when they use managed hosting. So the PHP extensions mechanism is in large part the problem here. If PECL extensions were 100% safe and could be loaded by userland using only PHP code then most of the pressure to see functionality is core could be relieved. That's why I floated the idea of supporting WASM in core.
> But I'm probably the only one who think much more extensions > should be removed from php-src and maintained outside, in pecl.
Let me guess. You or your team manages your PHP servers, you don't use managed hosting? -Mike
  109259
March 23, 2020 22:53 johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)
On Mon, 2020-03-23 at 11:01 -0400, Mike Schinkel wrote:
> > On Mar 23, 2020, at 6:36 AM, Remi Collet <remi@php.net> wrote: > > > > Le 21/03/2020 à 23:52, Mike Schinkel a écrit : > > > > On Mar 21, 2020, at 5:59 PM, tyson andre < > > > > tysonandre775@hotmail.com> wrote: > > > > FROM: Re: [PHP-DEV] [RFC] is_literal() > > > > > > > > And if it can be implemented as a PECL module, that would be > > > > more preferable to me than a core module of php. > > > > If it was in core, having to support that feature may limit > > > > optimizations or implementation changes that could be done in > > > > the future. > > > > > > Just wanted to address this comment which was made on another > > > thread (I did not want to hijack that thread.) > > > > > > A large number of PHP users have no control over the platform > > > they run on, so the option to use PECL modules is a non-starter > > > for them. > > > > Sorry, but PECL is the usual way for new extension > > > > - add to pecl > > - people start using it > > - if success add to php-src > > > > And later > > > > - move to pecl extensions removed from php-src > > Yes, it is the usual way. Which from my perspective is flawed > because it means that a large population of PHP developers can never > use those extensions. >
Bundling doesn't make much of a difference. Only force-enable (like we do with ext/standard, date, SPL and few others do) does. Most users use distribution-provided packages of PHP. For those Core or PECL matters little. Distributors package extensions in seperate packages, even if we consider them core. At the same time they ship pecl extensions. Thus whether one wants gd or some pecl extension is the same complexity. For somebody building PHP themselves compiling a PECL extension isn't too difficult either. For Windows pecl produces builds where we can, while users have to install by hand. Awarness however is different ... johannes
  109276
March 24, 2020 15:11 thruska@cubiclesoft.com (Thomas Hruska)
On 3/23/2020 3:53 PM, Johannes Schlüter wrote:
> For Windows pecl produces builds where we can, while users have to > install by hand.
Yeah, I've noticed this and thought about building a tool to help automate installation. However, it would be much easier to use PECL extensions on Windows if PHP on Windows actually had a simple way to add all the DLLs in a PECL extension to *just* the 'ext' directory and not have to copy multiple DLLs all over the place. For example, imagick has a ton of imported DLLs that are referenced by the main extension DLL, which fails to load for a lot of people. Then they have to go searching Google to figure out how to fix it for each separate SAPI. I'm thinking the problem is something that can be remedied with SetDllDirectory(): https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-setdlldirectorya Or AddDllDirectory(): https://docs.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-adddlldirectory Depending on if WinXP support is still a thing and/or having multiple directories is even possible. Calling LoadLibraryEx() looks like it would be a pain to implement given that the only references in the entire code to "LoadLibrary" is pushed all the way back into m4/configure? As PHP parses the 'extension_dir' INI option, it could call the relevant function above to allow for loading additional DLLs from the same directory when loading extensions. Doing that would fix so many Windows loader related issues that people have with getting the precompiled PECL extensions to work on Windows (especially with mixed SAPI environments). -- Thomas Hruska CubicleSoft President I've got great, time saving software that you will find useful. http://cubiclesoft.com/ And once you find my software useful: http://cubiclesoft.com/donate/