Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80262
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <00a201d02ac7$406a4830$c13ed890$@tekwire.net>
References: <CAEPJdu=2oWiSCQOTkO1g5QDs4NrJwd5H14Jks17qrNu7-eQNVg@mail.gmail.com>
	<CAESVnVqAHJujo0anMi7QYhSZeErcfRVAJ=M7oQMG-huk-bxpCg@mail.gmail.com>
	<54AAF98B.4020709@gmail.com>
	<alpine.DEB.2.11.1501061120440.4080@whisky.home.derickrethans.nl>
	<CAEZPtU69a2MwH5aqigAUEp8+KcjR+w9pd81EvzvM1_z4ES34rQ@mail.gmail.com>
	<001b01d029bb$fa687fc0$ef397f40$@tekwire.net>
	<alpine.DEB.2.11.1501070959000.4080@whisky.home.derickrethans.nl>
	<CAEZPtU67htboPTt6PefLaEREbkobnPY=BpjKpRGg3B1o8xC0Vg@mail.gmail.com>
	<00a201d02ac7$406a4830$c13ed890$@tekwire.net>
Date: Wed, 7 Jan 2015 16:50:56 -0800
Message-ID: <CAEZPtU5m+U4-PCHzqRBOFweOzuj7VzFLNmRVXDUG8aFjeMcU7A@mail.gmail.com>
To: francois@tekwire.net
Cc: Derick Rethans <derick@php.net>, PHP internals <internals@lists.php.net>, 
	Sara Golemon <pollita@php.net>, Stanislav Malyshev <smalyshev@gmail.com>, 
	Benjamin Eberlei <kontakt@beberlei.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Extension Prepend Files
From: pierre.php@gmail.com (Pierre Joye)

hi Fran=C3=A7ois,



On Wed, Jan 7, 2015 at 2:14 PM, Fran=C3=A7ois Laupretre <francois@tekwire.n=
et> wrote:
>> De : Pierre Joye [mailto:pierre.php@gmail.com]
>>
>> ... here,
>> it is proposed to bundle scripts that will be executed at runtime like a=
ny
>> other script, except that nothing can be done with them, not even disabl=
e
>> them if not required (like using its own glue codes).
>
> I agree. Bundling scripts in extensions to execute them at each RINIT is,=
 IMO, not a good idea (mostly for performance reasons and lack of control, =
as you note), but I keep thinking that a mechanism to embed PHP scripts in =
extensions and make them available via a common stream wrapper can be usefu=
l. What I don't like is the fact to execute them automatically at every RIN=
IT. I prefer to let the extension free to load its PHP code when its logic =
decides it is needed.

Or let the extension defines a script to prepend, preload, whatever we
end to do.

It is however important, as you mentioned, to leave the engine and the
user the ability not to load it, at all.

>> Pickle integration is almost finished, that solves your worries about co=
mposer and pecl extensions.
>
> Both mechanisms can coexist. They are not incompatible and probably fulfi=
ll different needs.

Indeed, but I did not refer to separate releases here but the ability
for Composer to install extension. If a script is part of an extension
release, it will be installed as well.

> You are asking for a standard path for plain files linked to an extension=
. As putting the shared library and plain files together is not a good idea=
, what about something like this :
>
> <php-install-prefix>/lib/php/extensions/php/<extension-name>
>
> A C macro can be defined to provide the path to the extension C code, in =
order to avoid hardcoding it (this way, it could be modified in the future)=
.

I suppose you mean to the extension PHP code, right? That's what is
done already for include_path for example. It has to be system and
optionally loaded.

> At install time, we could say that every files under <extension-source-di=
r>/php/install, if this dir exists, are installed there.
>
> It is just an example but does it correspond to the mechanism you were th=
inking about ?

Yes, and it is very easy to do and maintained. At least compared to
bundling script into binaries. Our build scripts already support
installing custom files out of the box for example.

> What is not clear to me is the question of packaging/versioning/deploymen=
t. If you consider the PHP glue code is modified more often than the C code=
, which will be the most frequent case, how do you version/distribute parti=
al packages ? or do you deliver 2 packages with independent versioning and =
dependencies together ? In this case, should we define a versioning convent=
ion for both packages ?

It is up to the maintainers. I would not do separate releases as it
makes it hard to track or support. Doing more releases even to "only"
fix the PHP glue codes sounds like a good practice anyway.

Cheers,
--=20
Pierre

@pierrejoye | http://www.libgd.org