Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125313
Precedence: bulk
MIME-Version: 1.0
References: <642cb3ea-bf51-4832-8539-0540742000e1@app.fastmail.com>
 <AM8P250MB0170D0B5229EC7BA2D13609FE28B2@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
 <2c2f13b5-9cad-4bcc-b59f-01693e494bb3@heigl.org>
In-Reply-To: <2c2f13b5-9cad-4bcc-b59f-01693e494bb3@heigl.org>
Date: Tue, 27 Aug 2024 08:51:52 -0300
Message-ID: <CADK1yXK5rTudiJfO3bW4t=LztQMdutJ+npfnmO8NVzJujNa0-g@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Using and Mentioning Third-party
 Packages in PHP Documentation and Web Projects
To: Andreas Heigl <andreas@heigl.org>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000324dfc0620a8e0a0"
From: deleugyn@gmail.com (Deleu)

--000000000000324dfc0620a8e0a0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Aug 27, 2024 at 2:06=E2=80=AFAM Andreas Heigl <andreas@heigl.org> w=
rote:

>
> I see this a bid differently to be honest. While I understand that using
> third party packages in our internal tools might make things easier in
> the short term it will cause a lot or additional work in the long term.
>
> Currently we have a lot of small scripts that do one thing. And they do
> it for a long time with very little maintenance effort. Blowing these
> scripts up with third-party libraries will mean that we will have to put
> in much more maintenance effort for either keeping the dependencies up
> to date or mostly rewriting the script the moment a change needs to
> happen as the libraries will be outdated.
>
> There are though some actual console applications like Pdt where it
> might be valid to use third party dependencies. But also here I'd ask
> whether the maintainability will be increased. A totally different
> question though is whether we actually need to maintain a special tool
> for building the docs or whether we can use a pre-existing tool for
> that. I am mainly thinking about either phpDocumentor or a default
> docbook renderer. But that is a totally differnt topic IMO.
>
> So I'd see this exactly the other way around:
>
> usage for infra needs very careful consideration to not increase the
> maintenance-burden on those that actually 'do' the maintenance.


I like the fact this has been brought up as it seems an equally important
consideration from my perspective. On one hand I remember reading about how
PHP Internals could hugely benefit from more volunteers to help maintain
the auxiliary projects of the language - which doesn't require C knowledge.
Perhaps this 'need' might be outdated now with the Foundation hiring
employees to work on PHP. On the other hand there's this really good point
about not creating a burden for existing maintainers of existing tools.
Ultimately, I find it important to consider that a tool that has been
"mostly no maintenance cost" for 10~20 years, then it might be following
PHP development practices so long gone that it's harder to capture new
volunteers. I understand there's a historical context in the 2000's where
PHP frameworks would come and go and most companies had their own in-house
framework. That reality is long-gone and community projects like Symfony,
Laravel and Composer are sustainable businesses that simultaneously rely on
PHP and make PHP better. Nowadays it is unlikely that a PHP developer will
pick up greenfield work with the language without using some reliable tool
provided by the community.

As it has been said, it is a disservice to the PHP project to be stuck on
vanilla PHP for things that require improvements, maintainers, revamp, etc.

--=20
Marco Deleu

--000000000000324dfc0620a8e0a0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Tue, Aug 27, 2024 at 2:06=E2=80=AF=
AM Andreas Heigl &lt;<a href=3D"mailto:andreas@heigl.org">andreas@heigl.org=
</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<br>I see this a bid differently to be honest. While I understand that usin=
g <br>
third party packages in our internal tools might make things easier in <br>
the short term it will cause a lot or additional work in the long term.<br>
<br>
Currently we have a lot of small scripts that do one thing. And they do <br=
>
it for a long time with very little maintenance effort. Blowing these <br>
scripts up with third-party libraries will mean that we will have to put <b=
r>
in much more maintenance effort for either keeping the dependencies up <br>
to date or mostly rewriting the script the moment a change needs to <br>
happen as the libraries will be outdated.<br>
<br>
There are though some actual console applications like Pdt where it <br>
might be valid to use third party dependencies. But also here I&#39;d ask <=
br>
whether the maintainability will be increased. A totally different <br>
question though is whether we actually need to maintain a special tool <br>
for building the docs or whether we can use a pre-existing tool for <br>
that. I am mainly thinking about either phpDocumentor or a default <br>
docbook renderer. But that is a totally differnt topic IMO.<br>
<br>
So I&#39;d see this exactly the other way around:<br>
<br>
usage for infra needs very careful consideration to not increase the <br>
maintenance-burden on those that actually &#39;do&#39; the maintenance.</bl=
ockquote></div><div><br></div>I like the fact this has been brought up as i=
t seems an equally important consideration from my perspective. On one hand=
 I remember reading about how PHP Internals could hugely benefit from more =
volunteers to help maintain the auxiliary projects of the language - which =
doesn&#39;t require C knowledge. Perhaps this &#39;need&#39; might be outda=
ted now with the Foundation hiring employees to work on PHP. On the other h=
and there&#39;s this really good point about not creating a burden for exis=
ting maintainers of existing tools. Ultimately, I find it important to cons=
ider that a tool that has been &quot;mostly no maintenance cost&quot; for 1=
0~20 years, then it might be following PHP development practices so long go=
ne that it&#39;s harder to capture new volunteers. I understand there&#39;s=
 a historical context in the 2000&#39;s where PHP frameworks would come and=
 go and most companies had their own in-house framework. That reality is lo=
ng-gone and community projects like Symfony, Laravel and Composer are susta=
inable businesses that simultaneously rely on PHP and make PHP better. Nowa=
days it is unlikely that a PHP developer will pick up greenfield work with =
the language without using some reliable tool provided by the community.=C2=
=A0<div><br></div><div>As it has been said, it is a disservice to the PHP p=
roject to be stuck on vanilla PHP for things that require improvements, mai=
ntainers, revamp, etc.<br clear=3D"all"><div><br></div><span class=3D"gmail=
_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature"=
><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div d=
ir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">Marco Deleu</div></div></div><=
/div></div></div></div></div></div></div>

--000000000000324dfc0620a8e0a0--