Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125311
Message-ID: <383252f6-d0e8-4f29-8f01-a71e5ed26d90@gmx.de>
Date: Tue, 27 Aug 2024 13:46:39 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] [Discussion] Using and Mentioning
 Third-partyPackages in PHP Documentation and Web Projects
Content-Language: de-DE
To: Andreas Heigl <andreas@heigl.org>, internals@lists.php.net
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>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
UI-OutboundReport: notjunk:1;M01:P0:qxvRTw1Pi2M=;0+8S/475APlBCV3U/A6nA9fdeCz
 NLHuZh7Rp7FuFb4UJ7T4TIsY8wwXCy4tbzmvUI6zHveAtblk94D0VR4EuUhx5fcYl3Gb2eFfs
 nzODWoxLq7FlnesBQfBvPbRQgBZXxBpwLVMQLaT6b3PMcXeDZRxKde3NF6rcEocTtWuA3qaII
 RWYfRpw1W2S20vdo/yEx7gGG9Czio4cjLXkS/Cpn0YILfr8MBTi83WbxD3p2x+33PxjiGalo7
 NNxHYAfVvqfq2oc6CKAW/gOI7Qw9H6Z+v8//vcWTvQj+5CYyOMwyWUhNR06wyfPH6kSCt4KhU
 7COgMtjYE/1yd3sN+n92WE0FASqXwU+jqCt2amxCuGadxxk6vDk2WR7Y83sEyL2u/2oCShd+S
 2039B37JU0fjiGsF04AN/S3W2F5Y/4mOf7QWHvNybHMo9BvcEbFUap+6TAmKgs2y6380T93LH
 U/18j7hkg2HVx3hu1s487ZGKu5KJqEo76HA0raNPWevLAWZPfUk933PybAux3bGXxjkqP3adc
 6nIq7TQlGG+Q5bJqHNE/TkYmuC4hJuJmQbR8m7Gu36glPb3QhPz01ow6YkLuDpClwqt/LmhQX
 THXtjbesxPp0sX2RBusaBVBxzqejkyqoDoDrYHG2QmyQjrEk85UfknL38vdEeAK7T8bff8nut
 kKNAy/kTVQuHraT0uNSp1MajJUdgjHk9l/h190syQxaIiUTT3TRiKvHaszmfuhhe4i9aaDUyN
 qKHgLt4Lu2O8ARgD4fqNT8PLcErfrtMLeiclC7FdWBLntdgLB6XC7fyDQFKprGyDhciYpLnPG
 lSZGdW1gJw1iYqzlMb8q+ZYAyCwTwF7ufNRAJ4pdP9VPE=
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 27.08.2024 at 07:03, Andreas Heigl wrote:

> 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.

Well, the RFC is not about that projects *should* use some tools or
libraries or frameworks, but rather that they *can* choose to do so if
they deem it valuable.  Of course, the projects should not only look at
the short term benefit, but also on the long term maintenance burden.

For instance, web-php introduced Composer about two years ago, and in
the following added support for php-cs-fixer and phpunit to be able to
enforce a certain coding style and to run some tests.  The maintenance
burden appears to be low (and might be lowered by ignoring dependabot).

Or another example would be the php-sdk-binary-tools.  That code base
had been originally developed for late PHP5 versions, and as such is
showing cracks, and given that it is not extensively used, some long
standing bugs have not even been noticed.  Just by running some static
analysis I easily found a couple of minor and not so minor issues.  I
consider it helpful to actually add some static analysis tool(s) to the
repo (instead of setting this up locally, and running only
occassionally), and maybe in the long run to also have some automated test=
.

Yet another example is web-pecl, which has quite some bugs, but
apparently nobody has a test environment set up, so fixing a bug may
introduce another (BTDT).  Some tooling may be helpful there.

Note that I have no intentions of rewriting these projects on top of a
framework, but tooling and maybe a few libraries should make things
easier for the respective developers, even in the long run.

Christoph