The current plan is to have one library dir and one extras dir (I hope these are the packages you're referring to).
,Wil > -----Original Message----- > From: Eric Coleman [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 23, 2008 12:14 PM > To: Zend Framework General > Subject: Re: [fw-general] ZF Packaging > > I got a question that I didn't see asked :p > > Are the 2 packages going to be seperated in subversion, or will it > remain the same SVN wise? > > I only ask because of my current use of svn:externals to include trunk > into my project (it's still in development) > > Regards, > Eric > > On Jan 23, 2008, at 2:42 PM, Wil Sinclair wrote: > > > So, not being one to leave important issues hanging, I'll let all of > > you in on our thinking WRT PEAR here at Zend. While PEAR is a great > > packaging and distribution tool, many of our users really appreciate > > the simple tarball installation we currently offer; this is > > something we get a lot of positive feedback on. Suffice it to say, > > whatever we do vis a vis PEAR is unlikely to entirely replace the > > current method of distribution. > > > > At this point, we don't see enough value in establishing a PEAR > > channel and packaging ZF for PEAR to commit Zend resources to do > > this for every release (remember we're trying to release > > functionality early and often, so release overhead must be kept to a > > minimum). That said, there are no terms in the licensing of ZF that > > prevent another party from packaging ZF for PEAR as they see fit and > > creating a PEAR channel. We could even consider hosting this if > > someone makes the significant commitment to keep it current and we > > can agree on the packaging. That would be a discussion for *after* > > someone has shown that they are dedicated to this project (probably > > by establishing an existing PEAR package(s) for a few releases) and > > has put together a proposal for us to consider. > > > > 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]> > <mailto:[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]> > <mailto:[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/> > <http://www.openideurope.eu/ > > > * > > > > > > > > ----- Original Message ---- > > From: Wil Sinclair <[EMAIL PROTECTED]> <mailto:[EMAIL > > PROTECTED]> > <[EMAIL PROTECTED] > > > <mailto:[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 > > > > > > > > > > > > > > > > > > > > > >
