Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:95686 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 71406 invoked from network); 6 Sep 2016 07:17:26 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 6 Sep 2016 07:17:26 -0000 X-Host-Fingerprint: 90.254.11.191 unknown Received: from [90.254.11.191] ([90.254.11.191:14477] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C9/2F-45301-38D6EC75 for ; Tue, 06 Sep 2016 03:17:25 -0400 Message-ID: To: internals@lists.php.net References: In-Reply-To: Date: Tue, 6 Sep 2016 08:17:20 +0100 Lines: 158 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Newsreader: Microsoft Windows Live Mail 16.4.3564.1216 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3564.1216 X-Posted-By: 90.254.11.191 Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle From: TonyMarston@hotmail.com ("Tony Marston") "Niklas Keller" wrote in message news:CANUQDCjeH45_2aEq74CCEOY4xc3xJ0o_+yRQ2NVy0K2VdOXFBQ@mail.gmail.com... > >Tony Marston schrieb am So., 4. Sep. 2016, 10:38: > >> "Rowan Collins" wrote in message >> news:b3bd7acf-a525-d921-1b1b-64ccf94b858b@gmail.com... >> > >> >On 02/09/2016 20:32, Davey Shafik wrote: >> >> I'd like to introduce a new RFC to deprecate pear/pecl (in 7.2, and >> >> remove >> >> in 8.0), as well as add composer/pickle (optional in 7.2, default in >> >> 7.3+) >> >> in their place. >> >> >> >> https://wiki.php.net/rfc/deprecate-pear-include-composer >> > >> >Hi Davey, >> > >> >I think this is a sensible idea. It basically accepts the reality that >> PEAR >> >is no longer the main place new users of PHP should look for 3rd-party >> >code. >> > >> >Thinking about the responses so far, I thought it would be useful to >> >enumerate just what PEAR is, and what is being proposed for removal. It >> >might even be worth adding a version of this to the RFC, in case it >> reaches >> >a wider audience who won't see this discussion. >> > >> >As I understand it, PEAR is: >> > >> >A1) A command-line package management tool for installing and updating >> >packages of PHP code over the Internet. >> >> Incorrect. There is a web interface which I use EXCLUSIVELY to maintain >> the >> contents of my PEAR library. > > >You only work in a web interface instead of an editor and version control >system? PEAR does not have a version control system. My software has an SVN repository, but that is totally unconnected with PEAR. My choice of editor has no bearing on the issue. I use the web interface to maintain PEAR on my local machine, and my hosting companies provide a web interface in their control panels. >Packagist has a web interface to add new packages. New versions >(maintenance) are published automatically once you push a new version tag. > >Any proposed replacement which does not have a >> web interface I'm afraid is totally unacceptable. Command line interfaces >> went out of fashion when the Windows OS was first released, and anyone >> who >> still insists on using one has not joined the rest of the world in the >> 21st >> century. >> > >The Windows OS doesn't even have a built-in SSH client to maintain remote >systems. Then use 3rd party software. There are several available. >Using a command line interface is much better for mintaining a server. No >web interface I'm aware of can compose different tasks as good as bash with >using pipes to filter, sort, reformat, ... That may be your personal opinion, but it is not shared by others. >I do NOT want the replacement PEAR library to be mixed in with my >> application code. >> > >It's not mixed. Every depenendy has it's very own directory within the >vendor directory. > >Pear instead mixes everything together by installing libraries globally. So what? >Global libraries work for Linux distributions as there's a team behind >carefully watching that things are compatible. But PHP applications are >from different vendors. There's nothing that prevents conflicts. > >I do NOT want the replacement PEAR library to update itself in the >> background. > >Composer doesn't do that. Then how come I've seen several complaints in various forums about composer updating libraries in the background and screwing things up. >It has to be under MY control or I simply won't install it. >> > >You're in full control. There's even a lock file so everyone installing an >app can install the same version of every depenendy. That way it's way >easier to reproduce bugs locally. > >It has to be 100% stable, and I'm not sure that composer/pickle fit the >> bill. >> > >I can't talk for pickle as I haven't used it as I usually do not use any >additional extensions or compile them in directly. > >But I have never had any issues with the stability of Composer. > >There may be a small number > > >I don't think it's a small number. Almost all projects I know use Composer. Exactly. Only the projects that YOU know use composer, but what percentage of all the PHP projects in the world does that cover? >The only one I know of that uses Pear is bugs.php.net. That proves nothing except that your knowledge is very limited. -- Tony Marston