# [RFC] Deprecate PEAR/PECL & Replace with composer/pickle - Thread: https://externals.io/message/95586 - Original archive: https://news-web.php.net/php.internals/95586 - Started by Davey Shafik on 2016-09-02T19:32:27+00:00 - Messages: 110 - Page 1 of 5: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/95586.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #95586 — Davey Shafik — 2016-09-02T19:32:27+00:00 URL: https://externals.io/message/95586#95586 Hi internals, 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 I highly recommend reading the twitter poll and accompanying thread at https://twitter.com/dshafik/status/756337267547832320 I believe that pickle solves the issues with regards to pecl, and have run the idea passed Jordi and Pierre. Both are fine with this RFC. :) I understand that adding in composer/pickle is just setting us up for having a future "Deprecate composer/pickle & Replace with foo/bar" RFC, so I've proposed the voting reflect that some people will just want to deprecate/remove pear/pecl and not replace them at all. I'm also proposing voting choices around the optional/default introduction of composer/pickle. - Davey --- ## #95587 — Davey Shafik — 2016-09-02T19:36:04+00:00 URL: https://externals.io/message/95586#95587 · In reply to: #95586 Also, just wanted to say: As a former fairly major contributor to PEAR (see: http://pear.php.net/user/davey) I understand that PEAR has a special place in the heart of many old-school PHP developers — but I believe that the community has spoken, through lack of action on PEARs part, and the rapid adoption of composer on the general communities part. We should probably also have some conversations about actually sunsetting the PEAR and PECL sites and deprovisioning those resources. But that's a whole other conversation ;) - Davey > Hi internals, > > 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 > > I highly recommend reading the twitter poll and accompanying thread at > https://twitter.com/dshafik/status/756337267547832320 > > I believe that pickle solves the issues with regards to pecl, and have run > the idea passed Jordi and Pierre. Both are fine with this RFC. :) > > I understand that adding in composer/pickle is just setting us up for > having a future "Deprecate composer/pickle & Replace with foo/bar" RFC, so > I've proposed the voting reflect that some people will just want to > deprecate/remove pear/pecl and not replace them at all. > > I'm also proposing voting choices around the optional/default introduction > of composer/pickle. > > - Davey --- ## #95589 — James Gilliland — 2016-09-02T19:57:18+00:00 URL: https://externals.io/message/95586#95589 · In reply to: #95586 > Hi internals, > > 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 > > I highly recommend reading the twitter poll and accompanying thread at > https://twitter.com/dshafik/status/756337267547832320 > > I believe that pickle solves the issues with regards to pecl, and have run > the idea passed Jordi and Pierre. Both are fine with this RFC. :) > > I understand that adding in composer/pickle is just setting us up for > having a future "Deprecate composer/pickle & Replace with foo/bar" RFC, so > I've proposed the voting reflect that some people will just want to > deprecate/remove pear/pecl and not replace them at all. > > I'm also proposing voting choices around the optional/default introduction > of composer/pickle. > > - Davey > Will composer/pickle address the unsolved PHP compatibility issue that makes pecl a pain following the PHP 7 release? --- ## #95590 — Davey Shafik — 2016-09-02T20:37:51+00:00 URL: https://externals.io/message/95586#95590 · In reply to: #95589 On Fri, Sep 2, 2016 at 12:57 PM, James Gilliland wrote: > > > > […] > remove > > […] > 7.3+) > > […] > run > > […] > so > > […] > introduction > > […] > Will composer/pickle address the unsolved PHP compatibility issue that > makes pecl a pain following the PHP 7 release? > Which, exactly? - Davey --- ## #95591 — David Walker — 2016-09-02T20:40:56+00:00 URL: https://externals.io/message/95586#95591 · In reply to: #95586 > Hi internals, > > 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 +1 A bunch of years back I tried contributing to a handful of PEAR_Auth packages and the 'maintainer' rejected them all on the basis of the PEAR library was mothballed with recommendation to use ZendFrameworks Auth packages. I know at least where I work we're migrating everything off of PEAR in deference to community maintained packages in composer. The only negative I could possibly see is a lack of a central, for lack of a better term, authority of PHP preferred packages for the multitude of services PEAR offers. But I don't necessarily see this as a major issue with the multitude of frameworksµframeworks that modularize all their bits and places like composer/packagist maintaining a growing list of packages. I guess PEAR served that purpose years ago in a more isolated PHP source environment, rather than today where it's heavily tracked and distributed. Cheers -- Dave --- ## #95592 — Ryan Pallas — 2016-09-02T21:17:20+00:00 URL: https://externals.io/message/95586#95592 · In reply to: #95586 > Hi internals, > > 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 > > I highly recommend reading the twitter poll and accompanying thread at > https://twitter.com/dshafik/status/756337267547832320 > > I believe that pickle solves the issues with regards to pecl, and have run > the idea passed Jordi and Pierre. Both are fine with this RFC. :) > > I understand that adding in composer/pickle is just setting us up for > having a future "Deprecate composer/pickle & Replace with foo/bar" RFC, so > I've proposed the voting reflect that some people will just want to > deprecate/remove pear/pecl and not replace them at all. > > I'm also proposing voting choices around the optional/default introduction > of composer/pickle. > I like the idea, my only concern is that pickle hasn't been committed to master in many months and the build is listed as failing. In fact the last release (v0.4 from what I can tell) also shows the build as failing? > - Davey --- ## #95595 — Lester Caine — 2016-09-03T08:18:48+00:00 URL: https://externals.io/message/95586#95595 · In reply to: #95586 > I'm also proposing voting choices around the optional/default introduction > of composer/pickle. Is Composer really all there is? I'm looking at the problems projects like tiki have with trying to keep composer working in an active project, and other projects have just as many bug reports of composer having failed again! Keeping the right combination of versions of third party libraries may be what it is intended to do, but it does not seem to achieve it. I make no bones about the fact that I don't like the way composer works, and warnings about "You are running composer with xdebug enabled. This has a major impact on runtime performance." Trying to set up an environment where composer only exists for PHP7 so it does not affect the legacy systems seems equally problematic. And Packagist has some many cross competing packages that it does not make providing a set of 'supported' php libraries at all feasible? I've just tried to get owncloud running again. I had it working fine in PHP5.3 days, but at some point an upgrade failed and while I managed to keep it working for a bit, it was not stable. I tries again last year but it was taking too long, so I switched tack this year, installed clean from the distribution and while it sort of installed it will not run and add the very thing I'm trying to restore, the mail package. I SUSPECT it needs composer somewhere under the hood, but getting white screen failures and no decent errors it's gone in the bin again. If composer is to replace PEAR then it needs to be properly supported INSIDE PHP as PEAR is and give the sort of support that PEAR currently provides to new users. Linux distributions once again provide their own views on how to combine composer and the other similar package managers for javascript, python and the like with their own manager and the situation is simply a mess! I've half a dozen package managers listed across the whole web framework base, and composer is not top of the list. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #95596 — Rowan Collins — 2016-09-03T10:20:18+00:00 URL: https://externals.io/message/95586#95596 · In reply to: #95595 >Is Composer really all there is? >I'm looking at the problems projects like tiki have with trying to keep >composer working in an active project, and other projects have just as >many bug reports of composer having failed again! Keeping the right >combination of versions of third party libraries may be what it is >intended to do, but it does not seem to achieve it. Interesting, can you give any details of these problems? I've always found composer to do its job very well indeed, and have heard nothing but good things about it. I did a quick search for "tiki composer" and found a page with lots of teething problems from 3 years ago, but I suspect many of those are long since fixed. There's some interesting questions around how to use it for optional plugins, which I hadn't thought about before, but PEAR doesn't do anything to help there either, so not really relevant to this discussion. > warnings about "You are running composer with xdebug enabled. This >has a major impact on runtime performance." So you don't like that the tool defaults to giving you a warning, which can be suppressed, to explain why it might seem slow, due to a debugging tool documented as not being suitable for production because it may have a performance impact? I imagine PEAR runs slower as well, it just doesn't default to telling you so. > Trying to set up an >environment where composer only exists for PHP7 so it does not affect >the legacy systems seems equally problematic. Do you mean having a single codebase that can be installed with or without composer? Mostly that's just a case of creating alternative autoloader / bootstrap files, since all the code knows about composer at runtime is "require 'vendor/autoload.php';" > And Packagist has some >many cross competing packages that it does not make providing a set of >'supported' php libraries at all feasible? There is some truth in this, pear.php.net was a curated package library, whereas packagist.org is an open publishing platform. The problem is that for something to be curated somebody has to spend time curating; mostly, the people doing that right now are the big frameworks like Symfony, although there are a few projects like PHP League. The idea behind PHP-FIG is also relevant: rather than PEAR only allowing packages that follow a certain style, users can see on an open market which packages advertise their compatibility. >If composer is to replace PEAR then it needs to be properly supported >INSIDE PHP as PEAR is and give the sort of support that PEAR currently >provides to new users. What kind of support are we talking about here? My experience of PEAR is "pear install foo" and in composer that would be "composer require somebody/foo", so I'm interested which scenarios you think need extra work. Regards, -- Rowan Collins [IMSoP] --- ## #95597 — Rowan Collins — 2016-09-03T14:45:13+00:00 URL: https://externals.io/message/95586#95597 · In reply to: #95586 > 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. A2) A curated default "channel" for the package management tool, at pear.php.net A3) The coding style guidelines for publishing on that channel A4) An ecosystem of packages built to those guidelines While PECL is: B1) A related command-line tool for managing extensions to PHP itself. B2) A default channel for the extension management tool, at pecl.php.net The command-line tools (A1 and B1 above) are currently distributed with PHP by default, and this is what we are looking to deprecate. Composer is the common choice to fill the role of A1, and "pickle" is being proposed as the official replacement for B1. Everything else will still be there, including the ability to download the tools, probably through your OS or stack's package management system. As to the rest, a few rambling thoughts: - There is no single replacement for pear.php.net. packagist.org partially fulfils job A2, but it is a marketplace, not a curated channel, and it doesn't do anything to standardise style (A3) or interoperability (A4). PHP-FIG is one attempt to fill that standardisation; it's entirely voluntary, and entirely separate from php.net, but it's not like anyone was ever forced to publish on pear.php.net. - pear.php.net is technically only one "channel" compatible with the tool, but I'm not sure how many others are out there in practice. As a random example, I know that Swift Mailer used to maintain a PEAR channel, but checking back it is now officially unsupported: http://pear.swiftmailer.org/ - On the flip side, many of the packages that are published on pear.php.net are also available on packagist.org for installation with composer, either in this list https://packagist.org/packages/pear/ or in unofficial forks. - The PEAR coding style would probably be considered "out of date" by a lot of PHP devs. That's partly a matter of fashion, but also a natural consequence of it predating certain language features - autoloading, namespaces, etc - which people want to take advantage of. - There is a "PEAR2" consisting of the "pyrus" tool, and pear2.php.net. It appears to be basically abandoned, although it is still prominently linked from pear.php.net. I assume pyrus never made into the default distribution of PHP? Regards, -- Rowan Collins [IMSoP] --- ## #95599 — Lester Caine — 2016-09-03T14:56:27+00:00 URL: https://externals.io/message/95586#95599 · In reply to: #95596 > > > […] > > Interesting, can you give any details of these problems? I've always found composer to do its job very well indeed, and have heard nothing but good things about it. I did a quick search for "tiki composer" and found a page with lots of teething problems from 3 years ago, but I suspect many of those are long since fixed. There's some interesting questions around how to use it for optional plugins, which I hadn't thought about before, but PEAR doesn't do anything to help there either, so not really relevant to this discussion. https://sourceforge.net/p/tikiwiki/mailman/message/35331374/ > > […] > > So you don't like that the tool defaults to giving you a warning, which can be suppressed, to explain why it might seem slow, due to a debugging tool documented as not being suitable for production because it may have a performance impact? I imagine PEAR runs slower as well, it just doesn't default to telling you so. But being able to set up an environment where it is easy to switch tools on and off is being complicated by having to manage different 'composer' setups. Something which I don't think it was actually designed to handle? > > […] > > Do you mean having a single codebase that can be installed with or without composer? Mostly that's just a case of creating alternative autoloader / bootstrap files, since all the code knows about composer at runtime is "require 'vendor/autoload.php';" This is perhaps my sticking point. I have a perfectly stable framework without the need for any 'autoloader', and a folder structure that works. Reworking the whole framework so that it follows the 'vendor' rules while still also just working with bog standard require_once in the right place is where I keep coming unstuck. > > […] > > There is some truth in this, pear.php.net was a curated package library, whereas packagist.org is an open publishing platform. The problem is that for something to be curated somebody has to spend time curating; mostly, the people doing that right now are the big frameworks like Symfony, although there are a few projects like PHP League. The idea behind PHP-FIG is also relevant: rather than PEAR only allowing packages that follow a certain style, users can see on an open market which packages advertise their compatibility. I don't think the current PEAR suite will disappear since it does provide a clean set of tools, and probably at least 80% of legacy systems still rely on it. I've just been stung by 'mcrypt' not being available with a couple of the owncloud alternatives I tried. They will not install on PHP7, and I think I'm going to have to roll back to PHP5.x to get that working. > > […] > > What kind of support are we talking about here? My experience of PEAR is "pear install foo" and in composer that would be "composer require somebody/foo", so I'm interested which scenarios you think need extra work. I WAS using SUSE's software management to keep all my production machines working cleanly. Currently that provides 5.6.9 along with every pear package I use. composer does not figure at all, but node, pip and bower all get support. Although I get the impression that a combination of npm with composer may be the way forward. npm can manage the development dependencies such as css tools as well as javascript management, but then do I actually need composer as well? Although I will ALWAYS prefer supplying the distributed library files I need from a local server rather than assuming they will remain available from some third party site, and it's that which I can't do with composer? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #95601 — Lester Caine — 2016-09-03T15:02:49+00:00 URL: https://externals.io/message/95586#95601 · In reply to: #95597 > - The PEAR coding style would probably be considered "out of date" by a > lot of PHP devs. That's partly a matter of fashion, but also a natural > consequence of it predating certain language features - autoloading, > namespaces, etc - which people want to take advantage of. A starting point for a replacement for PEAR might well be a style guide that lays out just how one should build a modern suite of code. My stumbling block deciphering owncloud is just how one does work out exactly what code has been loaded and from what files. Irrelevant if things just work, but when debugging an installation, the code flow should be easy to establish! -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #95602 — Rowan Collins — 2016-09-03T15:43:37+00:00 URL: https://externals.io/message/95586#95602 · In reply to: #95599 > > > […] > https://sourceforge.net/p/tikiwiki/mailman/message/35331374/ Right, so their problem was not with Composer itself, but with Satis, which is a tool for publishing or mirroring your own packages, like running your own PEAR channel. They wanted to update it for some reason, but couldn't because the server had a really old version of PHP, because it was running a really old version of Ubuntu. Elsewhere in the thread, they have problems downloading a particular version of a package from SourceForge. None of this sounds like something that PEAR, or any other alternative to Composer, would help with. > > […] > But being able to set up an environment where it is easy to switch tools > on and off is being complicated by having to manage different 'composer' > setups. Something which I don't think it was actually designed to handle? I'm not sure what you mean by that. Composer itself is distributed as a single PHAR file, and is governed almost entirely by the composer.json in your project, and pretty much everything can be different in every project. It's an awful lot easier to have multiple setups of that than PEAR, which is absolutely designed to manage central system-wide packages. > > > […] > This is perhaps my sticking point. I have a perfectly stable framework > without the need for any 'autoloader', and a folder structure that > works. Reworking the whole framework so that it follows the 'vendor' > rules while still also just working with bog standard require_once in > the right place is where I keep coming unstuck. Right, I remember switching to using an autoloader (long long before composer existed), and what a relief it was not to have to manage great lists of require_once everywhere any more. :) I think the only thing we had to fix was some class names being used as lower-case, when the filenames that needed including were camel-case. The simplest migration that occurs to me is "if ( file_exists('vendor/autoload.php') ) { require_once 'vendor/autoload.php'; } else { /* require all the individual dependencies as before */ }". > > […] > I WAS using SUSE's software management to keep all my production > machines working cleanly. Currently that provides 5.6.9 along with every > pear package I use. OK, so short story: you're not invoking pear directly anyway, so Davey's proposal to remove it won't actually affect you at all. > Although I will ALWAYS prefer supplying the distributed library files I need from a > local server rather than assuming they will remain available from some > third party site, and it's that which I can't do with composer? That's pretty much what Satis is for, as mentioned above. Or, if you're willing to pay, Toran Proxy, which is how Jordi gets the money to improve Composer. Regards, -- Rowan Collins [IMSoP] --- ## #95603 — Rowan Collins — 2016-09-03T16:11:10+00:00 URL: https://externals.io/message/95586#95603 · In reply to: #95601 > A starting point for a replacement for PEAR might well be a style guide > that lays out just how one should build a modern suite of code. My > stumbling block deciphering owncloud is just how one does work out > exactly what code has been loaded and from what files. Irrelevant if > things just work, but when debugging an installation, the code flow > should be easy to establish! As mentioned, that's exactly what PHP-FIG is doing; what you're talking about is exactly what PSR-1, PSR-2, and PSR-4 describe. You may not agree with the choices they made, like the people that made them, or approve of the processes they used, but all that would be just as likely if they happened to be hosted on a sub-domain of php.net. Regards, -- Rowan Collins [IMSoP] --- ## #95604 — Lester Caine — 2016-09-03T18:44:39+00:00 URL: https://externals.io/message/95586#95604 · In reply to: #95603 > > […] > > As mentioned, that's exactly what PHP-FIG is doing; what you're talking > about is exactly what PSR-1, PSR-2, and PSR-4 describe. > > You may not agree with the choices they made, like the people that made > them, or approve of the processes they used, but all that would be just > as likely if they happened to be hosted on a sub-domain of php.net. So this RFC is simply proposing that PHP-FIG becomes the standard for writing PHP code? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #95605 — Lester Caine — 2016-09-03T19:33:41+00:00 URL: https://externals.io/message/95586#95605 · In reply to: #95602 > > […] > > Right, I remember switching to using an autoloader (long long before > composer existed), and what a relief it was not to have to manage great > lists of require_once everywhere any more. :) I think the only thing we > had to fix was some class names being used as lower-case, when the > filenames that needed including were camel-case. The simplest migration > that occurs to me is "if ( file_exists('vendor/autoload.php') ) { > require_once 'vendor/autoload.php'; } else { /* require all the > individual dependencies as before */ }". The problem with that 'simple migration' is that currently I have nothing in the 'vendor/autoload.php' pot and everything in the 'individual dependencies'. I don't recognise the 'manage great lists of require_once everywhere' simply replacing 'vendor/autoload.php' with '../kernel/setup_inc.php' to load the framework. Yes the framework is something of a maze of functions and files, but it only loads a class when it needs it, and skips those it does not need. 15+ years of development starting back in PHP4 days. It's reworking 50+ major packages, pulling out the few files that make up the classes and repackaging them in 'vendor' format, while still having smarty plugins, templates, modules, admin tools and the like and managing just what tools a user has access to based on their role when accessing the site. In essence the composer setup is user specific if I am going down that path, and while making everything available and then not allowing access may be the modern way, only loading the sub-set of packages that the current job needs seems a lot faster to me. And if the user does not have access rights at all we only get as far as loading the access control functions, and throw an error page back. I do have a few third party elements. Smarty is now 'composer loadable', but ADOdb is not and has it's own db selected loader. But smarty is extended with additional local plug-ins so I don't see how there is any gain moving files around the file system rather than keeping them with their intended package. And returning to PEAR, if the relevant package is available, those functions are also switched on, or one falls back to defaults. The installer advises what it can and can't find, gives guidance to installing required tools and advise on optional ones. Something that is easy to do with the PEAR/PECL/dynamic extension system we currently have, but not so easy to manage with composer? A handler can obviously be written to edit the composer setup on the fly, and it's that sort of support I would expect if composer replaces PEAR. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #95606 — Yasuo Ohgaki — 2016-09-03T20:21:15+00:00 URL: https://externals.io/message/95586#95606 · In reply to: #95586 > > 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 +1 -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #95607 — Fleshgrinder — 2016-09-03T20:55:09+00:00 URL: https://externals.io/message/95586#95607 · In reply to: #95586 > Hi internals, > > 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 > > I highly recommend reading the twitter poll and accompanying thread at > https://twitter.com/dshafik/status/756337267547832320 > > I believe that pickle solves the issues with regards to pecl, and have run > the idea passed Jordi and Pierre. Both are fine with this RFC. :) > > I understand that adding in composer/pickle is just setting us up for > having a future "Deprecate composer/pickle & Replace with foo/bar" RFC, so > I've proposed the voting reflect that some people will just want to > deprecate/remove pear/pecl and not replace them at all. > > I'm also proposing voting choices around the optional/default introduction > of composer/pickle. > > - Davey > Clearly +1 -- Richard "Fleshgrinder" Fussenegger --- ## #95608 — Rowan Collins — 2016-09-03T21:53:35+00:00 URL: https://externals.io/message/95586#95608 · In reply to: #95604 > So this RFC is simply proposing that PHP-FIG becomes the standard for > writing PHP code? No, that is not at all what this RFC is proposing. The RFC is simply proposing to stop bundling the command-line tool "pear" with default PHP builds. The PEAR coding standards will still exist, the packages created according to them will still be usable, and you'll still be able to download pear, or pyrus, to access them. You could also use composer to access most of them, and publish packages adhering to that style on packagist.org, or pretty much any platform you want. The only reason I mentioned PHP-FIG is because they are trying to write a modern standard for writing interoperable PHP libraries, which is what you asked for. I guess we could have a philosophical debate about what it means for something to be "the standard" rather than "a standard", and whether PEAR was "more official" than PHP-FIG, and just who gets to decide what PHP is. But once again, I find myself being drawn into an off-topic debate about coding styles, and I would like to apologise to Davey as it has nothing to do with his RFC. Regards, -- Rowan Collins [IMSoP] --- ## #95609 — Davey Shafik — 2016-09-04T00:54:01+00:00 URL: https://externals.io/message/95586#95609 · In reply to: #95608 On Sat, Sep 3, 2016 at 2:53 PM, Rowan Collins wrote: > > > > […] > > No, that is not at all what this RFC is proposing. The RFC is simply > proposing to stop bundling the command-line tool "pear" with default PHP > builds. > > The PEAR coding standards will still exist, the packages created according > to them will still be usable, and you'll still be able to download pear, or > pyrus, to access them. You could also use composer to access most of them, > and publish packages adhering to that style on packagist.org, or pretty > much any platform you want. > > The only reason I mentioned PHP-FIG is because they are trying to write a > modern standard for writing interoperable PHP libraries, which is what you > asked for. > > I guess we could have a philosophical debate about what it means for > something to be "the standard" rather than "a standard", and whether PEAR > was "more official" than PHP-FIG, and just who gets to decide what PHP is. > > But once again, I find myself being drawn into an off-topic debate about > coding styles, and I would like to apologise to Davey as it has nothing to > do with his RFC. No need to apologize, thank you for defending my idea and so eloquently — I will amend the RFC with your earlier suggestions; being as I will do so almost verbatim, would you mind being added as a co-author? I think it's a substantial contribution :) - Davey --- ## #95611 — Tony Marston — 2016-09-04T08:38:06+00:00 URL: https://externals.io/message/95586#95611 · In reply to: #95597 "Rowan Collins" wrote in message news:b3bd7acf-a525-d921-1b1b-64ccf94b858b@gmail.com... > > > > […] > >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. 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. I do NOT want the replacement PEAR library to be mixed in with my application code. I do NOT want the replacement PEAR library to update itself in the background. It has to be under MY control or I simply won't install it. It has to be 100% stable, and I'm not sure that composer/pickle fit the bill. There may be a small number 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 --- ## #95612 — Lester Caine — 2016-09-04T08:48:33+00:00 URL: https://externals.io/message/95586#95612 · In reply to: #95608 > I guess we could have a philosophical debate about what it means for > something to be "the standard" rather than "a standard", and whether > PEAR was "more official" than PHP-FIG, and just who gets to decide what > PHP is. > > But once again, I find myself being drawn into an off-topic debate about > coding styles, and I would like to apologise to Davey as it has nothing > to do with his RFC. I think that what is missing is a discussion on just where one should start these days in terms of a basic framework for beginners. That there are so many competing "standards" that in many cases do not play well together is MY problem. That my key libraries ARE moving to a different style and have different ways of loading is a pull one way, and my web side interface has other loaders handling javascript and css packages which adds to the complexity. But perhaps we don't bother about the novice PHP user and just assume they are all simply using third party frameworks already so all that needs to be looked at is improving the library/framework developer experience. It would be nice to get back to some BASIC functionality such as loading a form, validating it's content, and string the results without having a dozen ways of filtering the inputs and a dozen ways of accessing the database. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #95614 — Leigh — 2016-09-04T10:22:58+00:00 URL: https://externals.io/message/95586#95614 · In reply to: #95586 > > I believe that pickle solves the issues with regards to pecl, and have run > the idea passed Jordi and Pierre. Both are fine with this RFC. :) > > I understand that adding in composer/pickle is just setting us up for > having a future "Deprecate composer/pickle & Replace with foo/bar" RFC, so > I've proposed the voting reflect that some people will just want to > deprecate/remove pear/pecl and not replace them at all. > > I'm also proposing voting choices around the optional/default introduction > of composer/pickle. I'm -1 on bundling composer and/or pickle. If people want this software it is trivial to obtain, and is far easier to keep up to date if it is managed out of band. --- ## #95615 — Niklas Keller — 2016-09-04T10:26:41+00:00 URL: https://externals.io/message/95586#95615 · In reply to: #95611 Tony Marston schrieb am So., 4. Sep. 2016, 10:38: > "Rowan Collins" wrote in message > news:b3bd7acf-a525-d921-1b1b-64ccf94b858b@gmail.com... > > […] > PEAR > > […] > reaches > > […] > > 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 --- ## #95616 — David Muir — 2016-09-04T10:32:07+00:00 URL: https://externals.io/message/95586#95616 · In reply to: #95612 > > > > […] > > I think that what is missing is a discussion on just where one should > start these days in terms of a basic framework for beginners. That there > are so many competing "standards" that in many cases do not play well > together is MY problem. That my key libraries ARE moving to a different > style and have different ways of loading is a pull one way, and my web > side interface has other loaders handling javascript and css packages > which adds to the complexity. > > But perhaps we don't bother about the novice PHP user and just assume > they are all simply using third party frameworks already so all that > needs to be looked at is improving the library/framework developer > experience. It would be nice to get back to some BASIC functionality > such as loading a form, validating it's content, and string the results > without having a dozen ways of filtering the inputs and a dozen ways of > accessing the database. > > -- > Lester Caine - G8HFL > ----------------------------- > Contact - http://lsces.co.uk/wiki/?page=contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk > Rainbow Digital Media - http://rainbowdigitalmedia.co.uk > > -- > > > How many competing autoloading standards are there? PSR-0 (PEAR, Zend, etc) and PSR-4 are the two main ones I know of. Symphony used to have their own style back in the day, but swapped to PSR-0 with Symfony2 8? years ago. I suppose you could also work with just a class map, which I've seen some libs use (eg TCPDF)... That said if you've got some other style, just register a loader for it and get on with it. Sounds to me like your problem isn't with Composer per se, but autoloading in general? Cheers, David --- ## #95619 — Tom Worster — 2016-09-04T13:48:16+00:00 URL: https://externals.io/message/95586#95619 · In reply to: #95586 > Hi internals, > > I'd like to introduce a new RFC to deprecate pear/pecl (in 7.2, and remove > in 8.0), Yes! It's good for the software (and its users) if it is maintained and contributed to using _currently_prevailing_conventions_ in f/oss. > as well as add composer/pickle (optional in 7.2, default in 7.3+) > in their place. Not so sure about this. While composer seems to be the currently prevailing convention for PHP deps right now (I don't know pickle), each project could instead have its own installation guide containing whatever makes sense (perhaps even something Windows-based for Tony). The PHP project could usefully maintain a policy on installation for the projects it has fingers in (PHP's a style guide to installation guides). But I don't think it helps to *dictate* those tools and methods and tie them to PHP releases. Just liberate the code and *encourage* uniform practices but let them evolve with some autonomy. Tom --- Next page: https://externals.io/message/95586.md?page=2