schlitt.info - php, photography and private stuff ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ :Author: Tobias Schlitt :Date: Thu, 27 Nov 2008 18:00:29 +0100 :Revision: 2 :Copyright: CC by-nc-sa =========================== New PEARs for the community =========================== :Description: On September 20th Greg Beaver (for a longer time now the main man behind the PEAR Installer) announced the stable release of the new PEAR Installer Version 1.4.0. Yesterday Gerg updated the release to an even more advanced version 1.4.1 which solves some minor bugs and adds some cool features for PECL developers. I think now it's time to write some introductional words about the new feature release of our Installer, which will steer the project into a completly new direction, since it's now possible for everybody to set up his own PEAR channel server and to distribute his applications comfortably through the PEAR Installer. On September 20th `Greg Beaver`__ (for a longer time now the main man behind the `PEAR`__ `Installer`__) `announced`__ the stable release of the new `PEAR Installer Version 1.4.0`__. Yesterday Gerg `updated the release`__ to an even more advanced version `1.4.1`__ which solves some minor bugs and adds some cool features for PECL developers. I think now it's time to write some introductional words about the new feature release of our Installer, which will steer the project into a completly new direction, since it's now possible for everybody to `set up his own PEAR channel server`__ and to distribute his applications comfortably through the PEAR Installer. .. __: http://greg.chiaraquartet.net/ .. __: http://pear.php.net .. __: http://pearadise.net/index.php/view/package/pear.php.net/PEAR/ .. __: http://greg.chiaraquartet.net/archives/88-RELEASE-ANNOUNCEMENT-PEAR-1.4.0-provides-revolution-in-PHP-Development.html .. __: http://pearadise.net/index.php/view/release/pear.php.net/PEAR/1.4.0/ .. __: http://greg.chiaraquartet.net/archives/89-PEAR-1.4.1-HIGHLY-recommended-upgrade.html .. __: http://pearadise.net/index.php/view/release/pear.php.net/PEAR/1.4.1/ .. __: /opensource/blog/0308_set_up_your_own_pear_channel.html I recommend to everyone out there to upgrade his/her PEAR installation to take advantage of the huge improvements, like: - Channel support. - Completly revised dependency handling. - Much more secure and performant REST web service backend. - Drastically enhanced PECL support. - Post install scripts. - ... For a full list and some introductory words, please refer to the extended entry. To upgrade your PEAR installation simply do *$ pear upgrade PEAR*. A *$ pear channel-update pear* is recommended afterwards. The new Installer version maintains BC to the old version, so you don't loose anything by upgrading, but gain For more info on what is new in PEAR 1.4 you should take a look at the extended version of this entry. So far, I'm very sure that our new version will be a milestone for installing and distributing PHP based source code (and maybe even other languages?) and that, with it's new exciting features and the fixed oddities of the old versions, it will become **_the_ standard for application distribution in the PHP world**. *Special thanks from my side to Greg, who did a really amazing job and worked like a horse to get everything done, and (self-evident) to anybody out there who helped with this.* PEAR the wold! ;) P.S.: And don't forget to register `your own channel server`__ on *pearadise.net - The PEAR channel portal*! :) .. __: /opensource/blog/0308_set_up_your_own_pear_channel.html `PEAR 1.4`__ is a huge milestone in the development of the `PEAR Installer`__. It is basically a rewrite of the `older version`__, enhanced by many exciting features and fixing almost any oddity. Although the release cycle has been drastically shortened (from beta to stable) by the need of a new stable version for PHP 5.1 (among other issues), the new version seems to be rock solid (after a first update), which is mostly caused by Greg's phantastic test suite (about 650 tests) and the help of many PEAR developers and users by testing the alpha and beta versions. .. __: http://pearadise.net/view/release/pear.php.net/PEAR/1.4.1/ .. __: http://pearadise.net/view/package/pear.php.net/PEAR/ .. __: http://pearadise.net/view/release/pear.php.net/PEAR/1.3.6/ **Update**: Thanks to Greg for some corrections. In following I'll try to provide a complete list of what has changed from 1.3.x to 1.4.1: - **Channels** - A channel is a `server application`__ that provides PEAR conform packages and can be used like the `PEAR channel`__ itself. Everyone can `set up his own channel`__ and provide his own applications through it. Users can then install and maintain the provided packages simply by `using the PEAR installer`__. The new commands *$ pear channel-``*``\* have been invented to allow users to add new channels to their PEAR installation (using *$ pear channel-discover channel.example.com*). - The new PEAR channels provide a different webservices interface than PEAR 1.3 utilized: REST. REST is a very simple and lighweight web service protocoll, that improves the speed of our Installer and makes it more secure than the former XML-RPC implementation was. PEAR 1.4 is able to utilize both web services, the old XML-RPC and the new REST, although the PEAR channel itself offers REST be now, too. The REST information provided by the channels is also aggregated on the PEAR channel portal `pearadise.net`__. - The new *$ pecl* command allows you to install packages from our partner project PECL without entering *$ pear install pecl/MyPackage* (because PECL now is a more or less independant channel) and offers some nice features for the installation (users) and packaging (developers) of PHP extensions (which is the purpose of PECL). A very good example for the usage of these features is the complex PHP extension PHP Data Objects (PDO). - **Dependencies** - The handling of dependencies has been widely improved with the new version. The definition of dependencies has been changed to a much more flexible way with the new package definition format package2.xml. - Dependencies are now resolved automatically by the Installer, if you want it: The switch "-a" makes the Installer grab all packages that are utilized by the one, you requested to install, from the web and install them first. The "-o" switch does the same, but loads only required packages and leaves optional dependencies out. - Dependencies are now checked before the package is actually downloaded (1.3 checked dependencies on the client side only) from the channel server, which reduces traffic, time and annoyance. - Also gained by the new package2.xml format is the possibillity to define dependency groups. This is extremly useful, if your package can provide more advanced features, which depend on other packages, but does not necessarily require them to be there to work in general. It e.g. allows users to do *$ pear install pear#webinstaller* to install the web frontend feature of the PEAR installer. - During uninstallation of a package the dependencies are now checked much more carefully, to reduce the risc of fragging a PEAR installation. Beside that, the new package2.xml allows to define that your package works definitly with a specific version of another package, but that it's not ensured to work with newer versions. This will also reduce the possibility of running into unexpected BC break problems. - The much more flexible definition of dependencies now allows `PECL packages`__ to be packaged and installed much more convenient. - Dependencies can not only point to packages provided through the `PEAR channel`__ itself or packages that simply lie on a webserver (using their URL), but also to any other package from `any other channel`__ (so called "cross channel depenencies"). Packages that get installed manually (not from a channel, but either locally or from a URL) are now checked for dependencies correctly, too. - **Remote installation & mirroring** - A major issue in the past was the possibility to install PEAR onto a shared hosting environment (what lot's of potential PEAR users propably want to / must do). All ways to achieve a private PEAR installation on a shared host (without shell access) required hard work and contained nasty pitfalls. The new `PEAR_RemoteInstaller`__ package enhances the PEAR installer to be able to install packages to a remote machine, using an FTP account. - If you want to maintain more than 2-3 servers with PEAR in your own network it can be a very good idea to mirror the PEAR repository (or any other channel) locally. This saves you much traffic and setup time, if your servers than access your local PEAR mirror. - **Packaging** - Another sweet new feature is the possibillity to package multiple packages into a single one. This basically means, that you can `create a package`__ which contains multiple other sub-packages, which get installed all together (or at least some together, as you like). A nice way to bundle e.g. PEAR packages (meaning library packages) together with your application. Each package can be upgraded on it's own (if you like) or just with your bundles (using the new dependency features). - **File roles & post install scripts** - The file role scheme of `PEAR 1.3`__ has been revised and now allows you to create custom roles for your files. File roles allow you to determine in general, what will happen with a specific category of files during the installation process (e.g. where to put the files, etc.). - Post install scripts are another new invention of 1.4. In 1.3 you could make the Installer perform simple tasks after installing your files (like replacing strings with environment dependent values). With `our new version`__ you can a) use the much more advanced integrated "tasks" (e.g. for doing the mentioned replacements) or even create tasks on your own, which can do anything that's possible with PHP (like copying files to directories outside the local PEAR dir, editing config files or initializing a database). - The API for `own post installation tasks`__ is really simple and offers a very nice interface to interact with the user during the installation process (which was not even possible in former times), like asking for installation pathes or configuration settings. - Post install scripts are not executed automatically, but require an explicit call to *$ pear run-scripts MyPackage*, for security reasons. I assume you don't want to have a package from a 3rd party channel perform a *$ rm -rf /* on your machine, or? If tasks exist that should be performed the Installer will inform about the scripts and how to run them. - **package2.xml** - As mentioned several times, the new Installer version brings `a new package.xml`__ version (the files are named package2.xml). This new format is a reworked version of `the old one`__, providing some great new features and fixing a lot of oddities (as one should already have noticed). - Packages which are packaged with `PEAR 1.4`__ can contain both versions in paralell, what makes the new packages backwards compatile (BC) to `older Installer versions`__, without loosing features if the new version is available. - To make the migration of packages smoother, the command *$ pear convert* has been introduced, which does a basic conversion form package.xml version 1.0 to 2.0. Because of the more complex features (like the new dependency model) some handwork is required to finish the migration. - A better way to maintain both versions in paralell is the usage of `PEAR_PackageFileManager`__ which generates both versions from 1 PHP source file and is very comfortable to use (package2.xml integrated since `version 1.6.0`__). - **PECL** - The brother project of `PEAR`__, `PECL`__, provides PHP extensions which are not delivered with PHP directly (mostly new extensions before they are added or uncommon ones, which have been moved here). In the old Installer version PECL packages were only supported very limited, what has been drastically improved by the following. - The new *$ pecl* command has been invented, which is almost a link to the *$ pear* command, but has `pecl.php.net`__ as it's defualt channel. Aside of that it has enhanced support for installing libraries into PHP by running without the php.ini. - As a special sugar the command *$pear pickle* was invented, which tries to downgrade a package2.xml to a package.xml. This shortcut is very limited, due to the fact that the conversion of package2.xml to package.xml is an extremly complex process and the command works very restrictive. - **Misc** - Beside the new commands mentioned during your way down here some more were added which shall be listed here. Additionally, there are some smaller, but neat enhancements, which do not fit into one of the categories above. - New commands for *$ pear list-files* lists all files that are in a package. - The equivalent for *$pear list-all* and *$ pear upgrade-all* for channels is *$ pear update-channels*. - The *$ pear list-all* and *$ pear remote-list* commands have status bars now (very convenient, since these may take extremly long with the number of PEAR packages). - Setting the new configuration setting "auto-discover" to 1 saves you from discovering every channel. You'll then have to use the long syntax *$ pear install channel.example.com/MyPackage* instead of the shortcut *$ pear install example/MyPackage* which is introduced by the *$ pear channel-discover*. **Please correct me if I made a mistake or missed something out! I'm pretty sure that this will be a great shot for the PEAR project.** .. __: http://pearadise.net/index.php/view/package/pear.chiaraquartet.net/Chiara_PEAR_Server/ .. __: http://pearadise.net/index.php/view/channel/pear.php.net/ .. __: /opensource/blog/0308_set_up_your_own_pear_channel.html .. __: http://pear.php.net/manual/en/installation.cli.php .. __: http://pearadise.net .. __: http://pearadise.net/index.php/browse/packages/pecl.php.net/ .. __: http://pearadise.net/index.php/browse/packages/pear.php.net/ .. __: http://pearadise.net/index.php/browse/ .. __: http://pearadise.net/index.php/view/package/pear.php.net/PEAR_RemoteInstaller/ .. __: http://pear.php.net/manual/en/guide.developers.package2.php .. __: http://pearadise.net/index.php/view/release/pear.php.net/PEAR/1.3.6/ .. __: http://pearadise.net/index.php/view/release/pear.php.net/PEAR/1.4.1/ .. __: http://pear.php.net/manual/en/guide.migrating.postinstall.php .. __: http://pear.php.net/manual/en/guide.developers.package2.php .. __: http://pear.php.net/manual/en/developers.packagedef.php .. __: http://pearadise.net/index.php/view/release/pear.php.net/PEAR/1.4.1/ .. __: http://pearadise.net/index.php/view/package/pear.php.net/PEAR/ .. __: http://pearadise.net/index.php/view/package/pear.php.net/PEAR_PackageFileManager/ .. __: http://pearadise.net/index.php/view/release/pear.php.net/PEAR_PackageFileManager/1.6.0a1/ .. __: http://pear.php.net .. __: http://pecl.php.net .. __: http://pearadise.net/index.php/view/channel/pecl.php.net/ .. Local Variables: mode: rst fill-column: 79 End: vim: et syn=rst tw=79 Trackbacks ========== - 3 years of blogging on Sat, 30 Sep 2006 11:58:19 +0200 in Tobias Schlitt - a passion for php Yes, it's true, exactly 3 years ago I wrote my first blog entry. By that time I would never have imagined, that I would keep blogging for more than 3 years and that more or less constantly. My weblog now contains 458 entries. Surely, there is some bulshit Comments ======== - Greg Beaver at Wed, 28 Sep 2005 05:52:54 +0200 That should read "since PEAR_PackageFileManager version 1.6.0", not 1.0.6 :) In addition, the pickle command will create the package.xml no matter what, as this is its sole purpose. A very nice summary of features. You even captured some things I have been taking for granted - it's hard to remember what is new and innovative when you've been living in the world of the PEAR internals for so long. - Lukas at Wed, 28 Sep 2005 10:09:27 +0200 I dont remember ever seeing such a complete list in the manual (then again I dont check it daily and it seems to be broken again ..), but maybe we should merge this list into the manual. - Toby at Wed, 28 Sep 2005 10:50:08 +0200 A good place for that would be our news section. - Christophe Gesché at Wed, 28 Sep 2005 16:18:53 +0200 **To upgrade your PEAR installation simply do $ pear upgrade PEAR.** Be care, on some distro pear is too old. do $ pear upgrade --all-deps PEAR-1.3.6 before do $ pear upgrade PEAR - Ben at Thu, 29 Sep 2005 01:39:05 +0200 I've been trying to figure out a good way to distribute entire web apps with pear. The tool works great for libraries but I'd like to distribute apps that depend on those libraries. Do I have to have users set 'data_dir' and put my web-facing files in there? It seems like there should be a 'web_dir' setting to go along with 'bin_dir', 'data_dir', etc. but maybe I'm just missing something. - Toby at Thu, 29 Sep 2005 08:51:08 +0200 I'd suggest you re-read the article again and I'm pretty sure that you'll find out, how installing real applications is made possible without something like a web_dir setting... OK? - Ben at Fri, 30 Sep 2005 01:46:47 +0200 Well, I see that you can create custom roles for your files. I thought that maybe something as common as seperating your web-facing files from backend classes might be built in. No problem - just trying to avoid reinventing the wheel :)