Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125839
Precedence: bulk
MIME-Version: 1.0
References: <92b537ac-62f4-435c-bf55-07223cfa1915@app.fastmail.com>
In-Reply-To: <92b537ac-62f4-435c-bf55-07223cfa1915@app.fastmail.com>
Date: Thu, 24 Oct 2024 00:57:27 +0100
Message-ID: <CAO__Xv4nyrZLRm9ROUQUHAHtsPOSszo5uFx4rZf4WzS8njTGCQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Policy on 3rd party code
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000157f4306252da892"
From: fenniclog@gmail.com (fennic log)

--000000000000157f4306252da892
Content-Type: text/plain; charset="UTF-8"

On Wed, 2 Oct 2024 at 19:37, Larry Garfield <larry@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
>   larry@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!

--000000000000157f4306252da892
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"g=
mail_attr">On Wed, 2 Oct 2024 at 19:37, Larry Garfield &lt;<a href=3D"mailt=
o:larry@garfieldtech.com">larry@garfieldtech.com</a>&gt; wrote:<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex">Since Jim&#39;s RFC proposa=
l was criticized for being too vague, I hereby offer a somewhat more prescr=
iptive policy proposal on using 3rd party code.=C2=A0 (With JIm&#39;s bless=
ing.)=C2=A0 It&#39;s still more heuristics than rules, but I think that&#39=
;s the right approach generally.=C2=A0 It also includes a voting mechanism =
to resolve edge cases when they come up.<br>
<br>
I&#39;m sure we&#39;ll bikeshed it to death, but please keep an open mind a=
bout the concept in the first place.=C2=A0 PHP is more than just php-src, a=
nd that&#39;s a good thing.=C2=A0 We need to catch up with that reality, wh=
ile at the same time maintaining a reasonable neutrality about projects Int=
ernals doesn&#39;t manage directly.<br>
<br>
<a href=3D"https://wiki.php.net/rfc/third-party-code" rel=3D"noreferrer" ta=
rget=3D"_blank">https://wiki.php.net/rfc/third-party-code</a><br>
<br>
*Puts on trusty flame-retardant suit*<br>
<br>
-- <br>
=C2=A0 Larry Garfield<br>
=C2=A0 <a href=3D"mailto:larry@garfieldtech.com" target=3D"_blank">larry@ga=
rfieldtech.com</a></blockquote><div><br></div><div>
<div>I remember a while ago a discussion about bundling composer with PHP b=
y default (and possibly dropping pear).</div><div>What ever happened with t=
hat?</div><div>As the first thing any dev does after setting up PHP, is ins=
tall composer. As this RFC points out, almost every project modern uses com=
poser to manage dependencies, and every Library, SDK and framework requires=
 composer.</div><div>So i&#39;d change this line in the RFC</div><div>&gt;=
=C2=A0
 We should use it, we should document it, we should promote it.</div><div>T=
o</div><div>
 &gt; We should use it, we should document it, we should promote it, we sho=
uld bundle it!

 </div>=C2=A0 <br></div><div>As I mentioned, it is basically a requirement =
nowadays to work in PHP unless you are doing something custom that doesnt r=
equire any dependencies, but then, is that person planning to release it to=
 the public?</div><div>I am of no opinion of weather php devs internally sh=
ould use composer, i have no skin in that game. But Documentation - Yes, Pr=
omotion - Yes, but does it really need it? Bundle it - Yes!<br></div></div>=
</div>

--000000000000157f4306252da892--