On Wed, 2 Oct 2024 at 19:37, Larry Garfield <la...@garfieldtech.com> wrote:
> Since Jim's RFC proposal was criticized for being too vague, I hereby > offer a somewhat more prescriptive policy proposal on using 3rd party > code. (With JIm's blessing.) It's still more heuristics than rules, but I > think that's the right approach generally. It also includes a voting > mechanism to resolve edge cases when they come up. > > I'm sure we'll bikeshed it to death, but please keep an open mind about > the concept in the first place. PHP is more than just php-src, and that's > a good thing. We need to catch up with that reality, while at the same > time maintaining a reasonable neutrality about projects Internals doesn't > manage directly. > > https://wiki.php.net/rfc/third-party-code > > *Puts on trusty flame-retardant suit* > > -- > Larry Garfield > la...@garfieldtech.com I remember a while ago a discussion about bundling composer with PHP by default (and possibly dropping pear). What ever happened with that? As the first thing any dev does after setting up PHP, is install composer. As this RFC points out, almost every project modern uses composer to manage dependencies, and every Library, SDK and framework requires composer. So i'd change this line in the RFC > We should use it, we should document it, we should promote it. To > We should use it, we should document it, we should promote it, we should bundle it! As I mentioned, it is basically a requirement nowadays to work in PHP unless you are doing something custom that doesnt require any dependencies, but then, is that person planning to release it to the public? I am of no opinion of weather php devs internally should use composer, i have no skin in that game. But Documentation - Yes, Promotion - Yes, but does it really need it? Bundle it - Yes!
