Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104002
MIME-Version: 1.0
References: <CAF+90c-B=xU9phGNxcRvZE+2c1RkKvsiDXU0qzWJdU_U3Tskag@mail.gmail.com>
 <7a909cd3-5d0f-8f2e-fba8-009778311bf0@php.net> <CAOwTYAspymG1HVBWSNGeuSK+gHcnBoxG599wqyD2-NDbOPeCfg@mail.gmail.com>
In-Reply-To: <CAOwTYAspymG1HVBWSNGeuSK+gHcnBoxG599wqyD2-NDbOPeCfg@mail.gmail.com>
Date: Sat, 2 Feb 2019 00:06:41 +0100
Message-ID: <CAAfnsFUiV25V=BO3+iU63FM3U0jKbnL5AOTL0=+x1tt6v3Agow@mail.gmail.com>
To: Joe Watkins <krakjoe@gmail.com>
Cc: Sebastian Bergmann <sebastian@php.net>, Internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Disable PEAR by default
From: peterkokot@gmail.com (Peter Kokot)

Hello,

On Fri, 1 Feb 2019 at 12:44, Joe Watkins <krakjoe@gmail.com> wrote:
>
> +1
>
> On Fri, 1 Feb 2019 at 12:35, Sebastian Bergmann <sebastian@php.net> wrote:
>
> > Am 01.02.2019 um 12:27 schrieb Nikita Popov:
> > > I would like to suggest that installation of PEAR is disabled by default
> > in
> > > PHP 7.4. PR: https://github.com/php/php-src/pull/3781
> >
> > +1

Thank you Nikita for the pull request for this. With all the respect
to PEAR project and people behind it, maybe the PEAR itself should be
added to some sort of recognition page in the manual for their
involvement and work on the first installer of PHP code and initial
move into code reuse, open source PHP libraries, and all that. As time
went forward, Composer took over the role of such installer in PHP
community. One of the most problematic issues and a reason for the
following questions is that I haven't noticed there has been any major
involvement in the past few years or some roadmap created for PEAR
(I'm not talking about PEAR packages here, only the PEAR core script).
Code itself is legacy and needs almost a complete rewrite. Omitting
things like PSR-4 makes coding with it very legacy, that's why it is
not recommended anymore. Why is PEAR even part of the php-src? From my
understanding, that is because of only one element/script. That is
pecl script. For everything else it can be downloaded separately, as
is Composer and all other tools needed for the usual daily workflow
with PHP.

So,

Q1: Shouldn't be a much better approach here to deprecate this
installation option in PHP 7.4 and remove it completely in PHP 8?

Q2: Follow up question, what to do with PECL scrip then? Is in PHP
even possible to start a new project such as a pecl command line tool
that would offer a replacement for current pecl script?

With only disabling installation option, nothing major is done
actually, I think but if there is some other plan here that +1 I
guess.

-- 
Peter Kokot