zfdev.com is a community supported project that never really took off, It was never an "official" repository though.
If someone is willing to maintain pear.zfdev.com I would be more then happy to get it back up and running. On Jan 27, 2008 8:07 AM, Simone Carletti <[EMAIL PROTECTED]> wrote: > AFAIK, an unofficial PEAR channel for Zend Framework has already being > created at http://code.google.com/p/zend/ > > Wil, I don't know if you noticed Zend Framework FAQ page talks about an > official(?) PEAR channel at http://pear.zfdev.com/ > http://framework.zend.com/wiki/display/ZFUSER/Frequently+Asked+Questions > Additionally, http://pear.zfdev.com/ is no longer available. > > I think this information should be removed. > Do you agree? > > Simone > > On Jan 23, 2008 8:42 PM, Wil Sinclair <[EMAIL PROTECTED]> wrote: > > > > > > > > > > In any case, there are- and almost surely will always be- those users who > won't want to use PEAR, and we will continue to make the installation > process simple for them. At this point it seems that the best option is a > tarball with possibly some CLI support for downloading some optional > code/data. We do appreciate the distribution/versioning/dependency > management issues in general packaging systems, and we certainly wouldn't > take on something this ambitious at this point. We'll only add support for > minimal distribution capabilities to the CLI if we can simplify requirements > for a ZF-specific setup in a way that doesn't have nasty side effects or > gets us in to dependency hell. > > > > > > > > Hope that sheds some light on the issue from our side. > > > > > > > > ,Wil > > > > > > > > > > > > > > From: Kevin McArthur [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, January 23, 2008 9:11 AM > > To: Pádraic Brady > > Cc: [email protected] > > > > > > > > Subject: Re: [fw-general] ZF Packaging > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > >
