Re: real-world example of (smart) developers using PEAR without installation

Alexey Borzov wrote: >> Actually, your choice of argument is quite interesting. For years, I >> maintained separate packages for phpDocumentor, one for unzip-and-go and >> one for installation via PEAR. This increased the complexity of a >> release tarball such that in several cases, the code didn't work in one >> of the releases quite right. > > I am confused: you are mentioning the "separate packages" and then > "complexity of *a* release tarball". Can you clarify what exactly were > the problems? Sorry. We released a different package through sourceforge than the one used in PEAR. Now that we use the same release structure for both, releasing is a lot simpler: pear package pear bundle PhpDocumentor-1.whatever.tgz zip PhpDocumentor/ PhpDocumentor-1.whatever.zip and uploading we go. Of course, because the zip extension is bundled with PHP 5 (we'll probably require 5.3+ because of namespaces), pyrus's packager will be able to handle tgz, zip and phar archives equally well, so packaging might become: pyrus package --with-zip This is irrelevant to the debate of course, as default download will probably remain .tgz, but I find it kind of exciting that this becomes both possible and easy :). >> Now that it is possible to do a tarball >> that works in both settings, the testing and development time has gone >> way down for phpDocumentor. So in spite of the vitriolic >> characterization of the work I've done (calling it "hacks" shows a lack >> of understanding, I think), there is no reason to give up - the idea >> works and it's worked quite well for a full year now. > > Yes, and you also bundle outdated versions of HTML_TreeMenu and Smarty > for PEAR-installed version of phpDocumentor instead of relying on > dependencies handling of PEAR installer. Right - one of the problems PEAR2 seeks to make possible to solve. We could actually remove HTML_TreeMenu from CVS, and pop it in at install from package.xml, or at packaging time, and add the contents to package.xml, or do a solution like the one you proposed below >> I can't quite tell if you intended to have a solution hidden in between >> the complains of your last message? Fortunately, I have limitless >> patience for potential solutions. > > The solution I suggest is to provide "PEAR bundles" semi-independent > of standard "PEAR packages". > > Instead of providing e.g. HTML_QuickForm_Renderer_Tableless package > which bundles HTML_QuickForm and HTML_Common (which is stupid, since > package's dependencies are several times larger than the package > itself) we provide a "HTML_QuickForm bundle" which consists of > HTML_QuickForm with HTML_Common and all QF's subpackages. > > This bundle may have a release schedule independent of the QuickForm > package, it can be re-released each time any of the packages inside > changes. With your approach we basically have to re-release a package > each time its dependencies change, or else unzip-and-go people will > have outdated dependencies. This is a great option to offer as a default. Some developers may wish instead to have slightly outdated dependencies but still have them bundled (phpDocumentor would be one of these) as it makes it easier to ensure upgrades to dependencies don't break the download. OK. I sense that we may be coming close to consensus. Where do we stand? Is there anything in either PEAR2_Standards or Controversial_Changes that is still controversial? Let's remember that Pyrus/PEAR2 is still somewhat in the distance, and as we understand the issues better, the solutions will be adapted to solve them. Having a starting point will make it a lot easier to do this, that is the primary goal of laying out the coding standard changes. In terms of timeline, I would like to imagine that packages can continue to be proposed to PEAR until Pyrus is fully functional, and then there should be a transitional period in which developers can choose which repository to propose to until Pyrus and the website are fully ready for PEAR2, then we could concentrate all new development in PEAR2, while allowing devs to provide full BC work on existing PEAR packages if they wish to. I would like to target PHP 5.3.2 as our target PHP version, as I assume there will be crashes to work out in namespaces and other stuff along those lines. I will try to get Pyrus completely working by PHP 5.3.0. Here are the latest drafts: http://wiki.pear.php.net/index.php/PEAR2_Standards http://wiki.pear.php.net/index.php/Controversial_Changes Greg