Hey Christoph, hey all. Am 27.08.24 um 13:46 schrieb 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.
I would like to differentiate between "tools" and "dependencies".A tool is for me something that runs independently from the project it is used on and in the end the language it is written in is irrelevant as long as it does it's job. Static analysis tools like PHPStan or CS-Checker like phpcs are such tools.
The fact that these tools are also written in PHP is a mere detail but seems to be problematic. They could also be written in C, Go or Rust and nobody would question their usage. This seems odd. And for me their usage on anything related to php.net should under no circumstances be a problem.
Dependencies on the other hand are something that can not be used on it's own and something the project is (more or less) tightly coupled to.
*Those* are the ones I see problematic. But you are correct in stating that the project does not *have* to use dependencies but *can*.
As long as code-reviews or similar things make sure that only reasonable and absolutely necessary dependencies are used I have no issue with that. While PIE *is* a good way of thinking sometimes the maintenance-burden of NIH is lower.
My 0.02 €
Cheers
Andreas
--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas |
+---------------------------------------------------------------------+
| GPG-Key: https://hei.gl/keyandreasheiglorg |
+---------------------------------------------------------------------+
OpenPGP_signature.asc
Description: OpenPGP digital signature
