Re: [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

Tony Marston <TonyMarston@hotmail.com> 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? 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. 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, ... 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. 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. 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. The only one I know of that uses Pear is bugs.php.net. of developers out there who think that composer > is the best thing since sliced bread, but I'm not one of them, and I > strongly object to a small number of developers having the ability to > impose > their personal preferences on the rest of the community. > > -- > Tony Marston > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >