Hello :) On Sun, Oct 27, 2024 at 3:28 AM Jim Winstead <j...@trainedmonkey.com> wrote: > > There were more existing 3rd-party dependencies that should probably be added > to the policy text: > > https://news-web.php.net/php.internals/125769 > > Two I missed were JpGraph and Parsedown which are used by web-doc. (Currently > by side-loading JpGraph and having an old copy of Parsedown committed to > web-doc, I would hope to move those out as Composer dependencies if we decide > to allow that.) > > Jim
First, I want to extend my gratitude to all who keep this effort running, your efforts are truly appreciated and much needed! :) I've been following this thread and, while I understand the historical context and some of the off-topic discussions, I find myself a bit puzzled. Historically, the restrictions on what could be used for the php-web, php-doc, and other codebases were primarily about ensuring that mirrors could operate using a stock PHP setup without additional dependencies like database servers. Over time, some services couldn't adhere to these restrictions, leading to various exceptions. It is important to note that php.net no longer has an official mirror program (see https://www.php.net/mirroring.php). Historically, the restrictions on what can be used for the php-web, php-doc, etc code base at large was about the mirrors (, for any of these services, could use it by using a stock PHP without anything else, be database servers etc. Some services obviously could not do it with these restrictions and 'exceptions' have appeared along the way. php.net does not have an official mirror program anymore (see https://www.php.net/mirroring.php), though mirrors still advertise themselves at https://www.php.net/mirror.php The principle that "php.net does not do promotional content" was, and still is, about avoiding explicit promotions of specific companies, products, or individuals. For example, all mirrors were listed in one place, and links/ads/etc from our homepage were never allowed. This is the context behind the stance of not promoting non-php.net entities. Regarding the tools we use in php.net projects, we already leverage a wide range of tools, services, and libraries, both PHP-based and otherwise. These can be seen in our repositories and elsewhere. Given that we no longer rely on a mirror network program per se, I don't see the issue with relaxing some of these strict rules. Doing so could make life easier and more enjoyable for maintainers, and likely improve the codebase by reducing the "Not Invented Here" syndrome or making things easier to maintain. Composer, for instance, has always wanted to remain independent from php.net, which is perfectly understandable. However, does this mean we can't use it? That seems like an overreaction in today's PHP development ecosystem. While it's true that anything can be done using a stock PHP setup without dependencies, this approach has not been ideal for many areas for quite some time. It is most certainly valid as well for many other tools or libraries. Last but not least, it might be a good thing (tm) to maintain a simple list of the tools we use and their purposes. This wouldn't be promotional but rather informative, helping everyone understand the current state of our toolset, improving transparency. best, -- Pierre @pierrejoye | http://www.libgd.org
