> 1. No versioned/split sub-packages. (decided long ago) Level of fine-graining is independent of PEAR in actual fact. Phing tasks which are three directory levels lower than the PEAR root can be packaged as individual PEAR packages so graining level is purely an administrative/convenience decision. Most of the time such fine-grain detail would not be required though - if you have a specific example you can bust this response easily though ;).
>2. Versioned paths in pear breaks pear standard operating method. May be confusing for that reason. Pear Upgrade ZendFramework _must_ be avoided if it will change files to newer functional versions. Versioned paths in PEAR do not break PEARs operating method - they are just not possible using the default installed PEAR which is unversioned and leans towards the latest of everything. What I've done in the past is simply create a new PEAR repository and update to a specific version requirement (installation of <5 minutes, plus scripted install -f calls) - that's significantly simpler with ZF since everything is by default versioned in common - if someone wants to downgrade a few versions on specific components I don't see the problem - PEAR has quite a few helpful install options (run "pear help install") for managing whether to update the package, the package but not all dependencies, etc. It's ripe for scripting a deployment to specific requirements. That said any personal requirement outside the norm will demand a customised solution or adaptation. I'm usually happy to just play tag with Phing as needed. If Zend_Build automated playing tag with the premier automator for PHP, then all would be good ;). >3. How would you deploy security fixes to existing version releases. How do you currently apply them given the versioned downloads we are discussing PEAR, which are not updated automatically for security fixes committed to the svn maintenance branch? Different problem to the one being discussed... >4. There has been talk/work on a CLI tool for bootstrapping anyway, just seems installation would be a natural extension as one command could download/install and bootstrap to prevent any pathing problems. PEAR doesn't create pathing problems - it uses the include_path like every other possible option discussed so pathing, pardon the pun, is relative. To use a specific PEAR version out of several just means you need to manage PATH so the right PEAR scripts are called from bash commands (or the equivalent for MS-DOS using set). I'm pretty sure given time and popular usage Zend_Build will have the exact same problems to be solved, that PEAR has had - mutiple installations, path management, fine-graining, package bundling, shared hosting installation without the CLI, etc. I do admit it's only fair to note PEAR is PHP4 - PEAR2 for PHP5 is still being waited for though it exists somewhere in SVN. I thought that was the first anti-PEAR argument I'd see since its the one I have little response to! Best regards, Paddy Kevin McArthur-2 wrote: > > No time for a big rant today, > > 1. No versioned/split sub-packages. (decided long ago) > 2. Versioned paths in pear breaks pear standard operating method. May be > confusing for that reason. Pear Upgrade ZendFramework _must_ be avoided > if it will change files to newer functional versions. > 3. How would you deploy security fixes to existing version releases. > 4. There has been talk/work on a CLI tool for bootstrapping anyway, just > seems installation would be a natural extension as one command could > download/install and bootstrap to prevent any pathing problems. > > K > > Pádraic Brady wrote: >> To remark on some of the PEAR FUD. >> >> PEAR doesn't remove the ability to download, decompress, copy and >> otherwise >> manually manage the source code - essentially it just takes a default >> action >> of downloading, decompressing, and copying into the /php/pear directory >> which should already be present on the PHP include_path in php.ini which >> alleviates one more include_path search for those getting a bit worried >> about having >2. The proposed download archives for Core/Extras/etc. can >> merrily continue their existence. They wouldn't even share the same >> subdomain... >> >> Does it preclude path versioning? I can script an entire PEAR system into >> existence using Phing based on any array of preferred version numbers - >> especially since PEAR does allow you to force installation of one >> specific >> version irrespective of it's status or age. Last I checked the basic PEAR >> installed in under 5 minutes. There is also version compatibility control >> built into PEAR since you can set a preferred-version on all dependencies >> package by package. This means control over specific preferred versions >> for >> any remote system is a doddle. The only manual intervention would be >> changing the include_path for the application... >> >> Finally, the ZF is a componentised framework - not a fragile stack of >> cards >> that will fall apart in PEAR - everyone did quite a good job of ensuring >> classes/components are decoupled. I would agree that at a minimum there >> would have to be a Core package of say the MVC components to form the >> basic >> installation base for immediate use - everything else could be made a >> self-contained package available across PEAR, with aggregated commands to >> install specific "bundles" of packages (perhaps reflecting the proposed >> download split). Then one could: >> >> pear channel-discover pear.framework.zend.com >> pear install zend/Zend_Core >> pear install zend/Zend_Services_Flickr >> pear install --force zend/Zend_Pdf-1.1.2 >> >> Not saying the PEAR route is any easier than whatever CLI option Will is >> considering - but PEAR does have the advantage of being in this >> distribution >> business for long enough to learn substantial lessons. The main >> disadvantage >> is packaging everything to start with - not a simple task and something >> for >> whoever maintains the current ZF build.xml to look into. At the moment >> for >> Phing, I'm leaning on work from Travis Swicegood who wrote a lean and >> mean >> PEAR packaging task for Phing over on pear.domain51.com. >> >> Best regards, >> Paddy >> >> >> Karl Katzke wrote: >> >>> A better example might be Python Eggs. You can unpack them to a >>> directory >>> of >>> your choosing using a simple CLI-bootstrap file. >>> >>> Symfony does use Pear, but Symfony is not very shared-hosting friendly >>> -- >>> and Zend *is* shared-hosting friendly, which is something that I would >>> very >>> much like to see the community maintain. >>> >>> -K >>> >>> On Jan 22, 2008 6:12 PM, Kevin McArthur <[EMAIL PROTECTED]> wrote: >>> >>> >>>> -1 from me on this idea. >>>> >>>> Pear updating something as fragile as the framework could cause all >>>> kinds >>>> of serious problems for sites using it as a shared library. >>>> >>>> It would be better to have a cli tool for framework installation.. a >>>> web >>>> installer like go-pear would probably be a better format for this. >>>> >>>> I'd also still continue to advocate when using a shared library >>>> approach >>>> that people use a versioned installation path like >>>> /usr/share/php/ZendFramework/ZendFramework-1.5 such that bootstrap >>>> files >>>> can pick their target versions explicitly. >>>> >>>> Kevin >>>> >>>> >>>> >>>> Wil Sinclair wrote: >>>> >>>> Actually, I'm a bit ignorant since I'm a relative PHP newbie, but let >>>> me >>>> turn that question around- why would a PEAR channel be a good way to >>>> distribute ZF? That is, considering the current ZF installation is >>>> basically >>>> download, decompress, and update include path, what does PEAR bring to >>>> the >>>> table that I'm missing? >>>> >>>> >>>> >>>> ,Wil >>>> >>>> >>>> >>>> *From:* Bryce Lohr >>>> [mailto:[EMAIL PROTECTED]<[EMAIL PROTECTED]>] >>>> >>>> *Sent:* Tuesday, January 22, 2008 2:13 PM >>>> *To:* [email protected] >>>> *Subject:* Re: [fw-general] ZF Packaging >>>> >>>> >>>> >>>> I second the request for PEAR channel. Is there any reason why that >>>> would >>>> not be a good way to distribute the framework? >>>> >>>> Regards, >>>> Bryce Lohr >>>> >>>> >>>> Pádraic Brady wrote: >>>> >>>> *Hi Will, >>>> >>>> It sounds good - an optional lean package would frighten off far less >>>> prospective users who have heard tales about HDD's dying from the >>>> strain >>>> of >>>> downloading the ZF ;). >>>> I would still like to see a PEAR channel emerge at some point though - >>>> that may be a fanciful concept but I gather from the last paragraph >>>> something along those lines is under consideration? >>>> Hope someone comes up with colourful names for these variants! >>>> >>>> Best regards, >>>> Paddy* >>>> >>>> >>>> >>>> *Pádraic Brady >>>> >>>> **http://blog.astrumfutura.com >>>> http://www.patternsforphp.com >>>> OpenID Europe Foundation <http://www.openideurope.eu/>* >>>> >>>> >>>> >>>> ----- Original Message ---- >>>> From: Wil Sinclair <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> >>>> To: [email protected] >>>> Sent: Tuesday, January 22, 2008 8:36:39 PM >>>> Subject: [fw-general] ZF Packaging >>>> >>>> As part of the 1.5 release process, we've been reviewing the size of >>>> our >>>> distribution package and what contributes the most weight. We've >>>> determined that there are a few 'heavyweights' that we currently have >>>> in >>>> the zips/tarballs that many- if not most- users will never need. These >>>> include the unit tests, the demos, and the locale files (currently >>>> consuming ~8MB uncompressed on my hdd :O). With these components, the >>>> 1.0.3 release is ~5.3MB compressed on my hdd. We would like to >>>> distribute, starting with the 1.5 RC1, a 'lean and mean' ZF package >>>> alongside the 'everything' package. The 'lean and mean' package would >>>> not contain the tests, demos, locale files, or extras. 'Everything' >>>> would include, well, everything- even docs in html format. To >>>> facilitate >>>> access to the omissions from the 'lean and mean' release, we would >>>> provide a download action for the CLI tool so they can be retrieved and >>>> installed in the correct place with a single command. >>>> Thomas can give more details about how the locale-aware components >>>> would >>>> behave in this proposal. >>>> Thoughts? >>>> >>>> Thanks. >>>> ,Wil >>>> >>>> >>>> >>>> >>>> >>> >> >> > > ----- Pádraic Brady http://blog.astrumfutura.com http://www.patternsforphp.com OpenID Europe Foundation - Irish Representative -- View this message in context: http://www.nabble.com/ZF-Packaging-tp15027830s16154p15048948.html Sent from the Zend Framework mailing list archive at Nabble.com.
