# Why Move to PECL? - Thread: https://externals.io/message/2253 - Original archive: https://news-web.php.net/php.internals/2253 - Started by James Cox on 2003-06-09T14:16:30+00:00 - Messages: 4 - 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 --- ## #2253 — James Cox — 2003-06-09T14:16:30+00:00 URL: https://externals.io/message/2253#2253 Thinking a bit about this topic, I thought I'd pen some thoughts as to why bother moving to PECL in the first place, just to put things into perspective. As an extension developer, PECL provides the following: -- your own release cycles. -- granular package management : want to be the only maintainer? Fine, this is no problem with PECL. As well as the other sourceforge-esque things that will come as people request them. As an end user (and dev), PECL provides the following: -- easier install path. (# pear install foo) -- no need to recompile... Useful in hosting environments where you may have chrooted apache/php.. This doesn't sound like much, however I think it's quite substantial, as it allows extension developers to provide different release cycles to the main php core. What does that mean for the PHP RM? -- less QA hassle. The only releases that would get sent out via a PHP RM would be --STABLE.tgz -- or in other words, packages that would have had, theoretically, a substantial amount of QA already, and so would require less attention from the PHP RM. That means that QA can focus on core language issues. -- smaller packages. We can provide php-lite, php-all, php-common packages. Php-lite would just incorporate the main core of php, and the pear/pecl tools. Php-all would be a complete bundle, with suggested libraries included, and php-common would be like php.ini-recommended. How do we get here? By moving PECL into the limelight. This week, I will be splitting PECL into it's own cvs module, and (after discussion) I'd like to create a version of pearweb for pecl.php.net, essentially seperating the PEAR and PECL projects. We can then start an upgrade path of getting packages into PECL. I am pretty sure that doing this kind of stuff will make life easier for our downstream users (ie, cc'ed Joe Orton, who packages RPMs for RedHat) as they more or less do this _already_ anyhow. We will (hopefully) make it easier for them so they can remove their hacks to do this. I think the feeling of throwing everything into PECL right now is probably flawed; as Rasmus said, we are at risk of forcing it to be something it's not right now, and I think this contravenes Stig's excellent management of PEAR (ie, do it right, don't hack it). So, the summary: Lets promote PECL somewhat. Lets make it work without all the minor problems right now (eg, secure binaries, win32 support, etc etc). Then once we are all using that instead of recompiles every time.. (which won't take long) moving to PECL becomes a natural progression. -- james -- James Cox :: james@imajes.info :: http://imajes.info/ Was I helpful? http://www.amazon.co.uk/exec/obidos/wishlist/23IVGHQ61RJGO/ The mind leads, the emotions follow. - Ayn Rand --- ## #2262 — Martin Jansen — 2003-06-10T09:21:27+00:00 URL: https://externals.io/message/2253#2262 · In reply to: #2253 > By moving PECL into the limelight. This week, I will be splitting PECL into > it's own cvs module, and (after discussion) I'd like to create a version of > pearweb for pecl.php.net, essentially seperating the PEAR and PECL projects. While I agree that it's a great idea to make more usage of PECL, I don't think that the plan to set up pecl.php.net as an independent site will help us much: It will result in having to maintain yet another site and fixing bugs in the codebase of pearweb and peclweb (which will be nearly identical) will eventually turn out to be a nightmare. Instead I suggest to make pecl.php.net an alias for pear.php.net and (optically) highlight the PECL packages there, so that interested users can more easily find them. (I offer to help you doing this.) This way PECL becomes more visible and we'll only have to maintain one site instead of two. -- - Martin Martin Jansen http://martinjansen.com/ --- ## #2265 — Pierre-Alain Joye — 2003-06-10T09:54:46+00:00 URL: https://externals.io/message/2253#2265 · In reply to: #2253 On Mon, 9 Jun 2003 15:16:30 +0100 "James Cox" wrote: > How do we get here? > > By moving PECL into the limelight. This week, I will be splitting PECL > into it's own cvs module, and (after discussion) I'd like to create a > version of pearweb for pecl.php.net, essentially seperating the PEAR > and PECL projects. I do not agree here with pecl.php.net. From the early days of PEAR, it contains PEAR and PECL, the roadmaps of PEAR was always to take care of PECL inside the PEAR infrastructure. Highlight PECL package inside pear.php.net is quit enough. As a sidenote, the installer currently does not support multiple master servers. Please do not split the whole things, I understand the need of splitting the cvs tree (even if I still do see all the pros/cons), but why do you want suddenly get PECL out of PEAR and still use the pear infrastructure? This is not the way we plan from months now. And I think we should not got this way. Even if some of the phpdev team actually discover the pear/pecl is not the siberia and is a nice system :) > So, the summary: > > Lets promote PECL somewhat. Lets make it work without all the minor > problems right now (eg, secure binaries, win32 support, etc etc). Then > once we are all using that instead of recompiles every time.. (which > won't take long) moving to PECL becomes a natural progression. Lets promote the "universal" installer infrastructure used by PECL as well (and fix/enhance it as said earlier). pierre ps: pear's don quichotte :) --- ## #2266 — Derick Rethans — 2003-06-10T10:02:08+00:00 URL: https://externals.io/message/2253#2266 · In reply to: #2265 > On Mon, 9 Jun 2003 15:16:30 +0100 > "James Cox" wrote: > > > […] > > I do not agree here with pecl.php.net. From the early days of PEAR, it > contains PEAR and PECL, the roadmaps of PEAR was always to take care of > PECL inside the PEAR infrastructure. I agree, I go with Markus' aliasing and highlighting thingy. > As a sidenote, the installer currently does not support multiple master > servers. Fix it! ;) regards, Derick -- "my other box is your windows PC" ------------------------------------------------------------------------- Derick Rethans http://derickrethans.nl/ International PHP Magazine http://php-mag.net/