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
