RE: [fw-general] ZF Packaging
Yeap, you’re pointing out exactly how high the tightrope is that we’re balancing on. :) The fact is, there are people out there right now- you might be one of them!- developing ZF components (components that play nicely with and likely depend on ZF ‘core’ components) that they would like to share with others either in their own company/projects and/or publically- and we haven’t addressed such components in any significant way as a framework. In fact, our proposal process right now is structured entirely around components on the ‘core’ track, and many perfectly useful components will never be serious core candidates because they aren’t useful to most developers for any number of reasons. I know that people really appreciate the simple packaging that we currently have with ZF, and we’re not about to take away one of the biggest value propositions to our developers. On the other hand, we’re growing rapidly as a community and a software package, and what made sense yesterday isn’t necessarily practicable today. I doubt any of us want a full packaging system, so it will be a matter of finding the right compromise AFAIC tell. We haven’t had much time to talk about it lately since many of us are so focused on 1.5, but soon after the release we will pick the discussion up again on this list. BTW, I greatly respect and sometimes even consult with my predecessors, but the course of ZF is set by the opinions of the ZF community *right now*. It may be hard to keep up sometimes, but that is pretty much the story of the software industry and OS community at large. And ZF has to keep up in its own right. ;) ,Wil From: Kevin McArthur [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 05, 2008 11:28 AM To: Wil Sinclair Cc: Bradley Holt; Elliot Anderson; Simone Carletti; fw-general@lists.zend.com Subject: Re: [fw-general] ZF Packaging Wil, I'll play devils advocate here. First, before everything else one must consider deployment, packaging and installed base. One of the great failures with PDO, and possibly one of its successes, was with its separate driver architecture. Practically, splitting it makes sense, pragmatically however, it has lead to serious configuration headaches for a lot of users. Zend Framework is the same, and your predecessors have expressed the importance in making sure that when a hosting package is selected that says 'Zend Framework v 1.X' it means all of it -- not a mix of components that will have to be detected at runtime. Worse, we could end up with independently versioned components aside from the core. Applications dependent on framework will then have to made even more intelligent, and deployment complexity increases significantly. I would point you to review the archives here, as versioning and optional components have been discussed at length before. There is something very powerful about Zend's currently unified deployment architecture. Kevin Wil Sinclair wrote: I generally like mootools’ and other JS libraries simplistic dependency model (AFAIC tell, the core lib is the only dependency allowed, so a general-purpose packaging system with tracking across full dependency graphs is not necessary). If we were to start distributing parts of ZF in a piecemeal fashion, I think that we would also see great benefit from a few basic rules aimed at drastically simplifying dependency management. While there is no immediate and significant runtime advantage that I can see here, we are interested in- and have been discussing- distributing at least one ‘lean and mean’ archive. There are several reasons for this, including lower load on our servers and- taking off my perfectly logical developer hat and putting on a more realistic marketing hat ;)- the fact that many developers and reviewers consider distribution size to be an important dimension on which to judge a framework. I don’t necessarily think that distribution size is a good indication of anything for a server-side framework beyond what you *can’t* expect to be included, such as sizable locale files which are very useful to our many international users but that add a MB or two to the current distribution of ZF (Thomas has done an excellent job getting these as small as possible while maintaining everything that makes them so useful in the first place), but I do think that the ‘download only what you need’ distribution mechanism is both technically and philosophically compatible with ZF in its current state. We’ll probably be talking about this more once 1.5 is out the door. ,Wil From: Bradley Holt [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 05, 2008 7:04 AM To: Elliot Anderson Cc: Simone Carletti; fw-general@lists.zend.com Subject: Re: [fw-general] ZF Packaging Elliot, The main reason that mootools does this, in my understanding, is so that it can give you one JavaScript file to be included in your web page with only the compon
Re: [fw-general] ZF Packaging
To put my unimportant word here :) Well I think that it's good practice to separate core and 'satellites'. Like the gdata in ZF ... well everyone (at least I do ;) have it in libs folder but little % of users is using it. But removing it would do nothing bad to the rest. If I could suggest the ZF could have the core (like the controller, actions, mvc part, session, ...) and 'satellites' (gdata, ldap, openid). The thing is that if you upload 'satellite' you'll keep it working just that ... no more things. We'll that's just me, and my few thoughts about ... P.S. Sorry Kevin for sending it duplicate to you :) I'm just hitting sometimes 'reply' button and this time it did wrong. -- Łukasz Wojciechowski
Re: [fw-general] ZF Packaging
Wil, I'll play devils advocate here. First, before everything else one must consider deployment, packaging and installed base. One of the great failures with PDO, and possibly one of its successes, was with its separate driver architecture. Practically, splitting it makes sense, pragmatically however, it has lead to serious configuration headaches for a lot of users. Zend Framework is the same, and your predecessors have expressed the importance in making sure that when a hosting package is selected that says 'Zend Framework v 1.X' it means all of it -- not a mix of components that will have to be detected at runtime. Worse, we could end up with independently versioned components aside from the core. Applications dependent on framework will then have to made even more intelligent, and deployment complexity increases significantly. I would point you to review the archives here, as versioning and optional components have been discussed at length before. There is something very powerful about Zend's currently unified deployment architecture. Kevin Wil Sinclair wrote: I generally like mootools’ and other JS libraries simplistic dependency model (AFAIC tell, the core lib is the only dependency allowed, so a general-purpose packaging system with tracking across full dependency graphs is not necessary). If we were to start distributing parts of ZF in a piecemeal fashion, I think that we would also see great benefit from a few basic rules aimed at drastically simplifying dependency management. While there is no immediate and significant runtime advantage that I can see here, we are interested in- and have been discussing- distributing at least one ‘lean and mean’ archive. There are several reasons for this, including lower load on our servers and- taking off my perfectly logical developer hat and putting on a more realistic marketing hat ;)- the fact that many developers and reviewers consider distribution size to be an important dimension on which to judge a framework. I don’t necessarily think that distribution size is a good indication of anything for a server-side framework beyond what you **can’t** expect to be included, such as sizable locale files which are very useful to our many international users but that add a MB or two to the current distribution of ZF (Thomas has done an excellent job getting these as small as possible while maintaining everything that makes them so useful in the first place), but I do think that the ‘download only what you need’ distribution mechanism is both technically and philosophically compatible with ZF in its current state. We’ll probably be talking about this more once 1.5 is out the door. ,Wil *From:* Bradley Holt [mailto:[EMAIL PROTECTED] *Sent:* Tuesday, February 05, 2008 7:04 AM *To:* Elliot Anderson *Cc:* Simone Carletti; fw-general@lists.zend.com *Subject:* Re: [fw-general] ZF Packaging Elliot, The main reason that mootools does this, in my understanding, is so that it can give you one JavaScript file to be included in your web page with only the components you need. There are performance advantages to this since you are only requiring the user's browser to get the JavaScript components it will need, not all of mootols. With Zend Framework, there is no performance advantage to only installing a handful of components. My understanding is that the performance hit comes when you require or include the component, not from it simply sitting on your web server. In other words, the main advantage of the pick-what-you-want download system doesn't apply when it comes to Zend Framework. The only advantage I can see is storage space, but have there been any complaints about that with Zend Framework? Thanks, Bradley On Feb 5, 2008 6:26 AM, Elliot Anderson <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: I'm a fan of the pick-what-you-want download system that Moo Tools has. http://mootools.net/download On Jan 29, 2008 6:04 AM, Simone Carletti <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: On Jan 28, 2008 3:57 PM, Richard Thomas <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: zfdev.com <http://zfdev.com> is a community supported project that never really took off, It was never an "official" repository though. Sorry Richard, my misunderstanding. :) Thanks for pointing it out. Simone -- Bradley Holt [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
Re: [fw-general] ZF Packaging
Will, One of the things I love about Zend Framework is that it is loosely coupled. Anything that encourages less inter-dependency amongst components (except where it makes sense) is certainly a good thing. I can definitely see the marketing benefit as well. As long as I have the option to keep getting my Zend Framework fix in one whole piece I'm happy ;-) Thanks, Bradley On Feb 5, 2008 2:06 PM, Wil Sinclair <[EMAIL PROTECTED]> wrote: > I generally like mootools' and other JS libraries simplistic dependency > model (AFAIC tell, the core lib is the only dependency allowed, so a > general-purpose packaging system with tracking across full dependency graphs > is not necessary). If we were to start distributing parts of ZF in a > piecemeal fashion, I think that we would also see great benefit from a few > basic rules aimed at drastically simplifying dependency management. While > there is no immediate and significant runtime advantage that I can see here, > we are interested in- and have been discussing- distributing at least one > 'lean and mean' archive. There are several reasons for this, including lower > load on our servers and- taking off my perfectly logical developer hat and > putting on a more realistic marketing hat ;)- the fact that many developers > and reviewers consider distribution size to be an important dimension on > which to judge a framework. I don't necessarily think that distribution size > is a good indication of anything for a server-side framework beyond what you > **can't** expect to be included, such as sizable locale files which are > very useful to our many international users but that add a MB or two to the > current distribution of ZF (Thomas has done an excellent job getting these > as small as possible while maintaining everything that makes them so useful > in the first place), but I do think that the 'download only what you need' > distribution mechanism is both technically and philosophically compatible > with ZF in its current state. We'll probably be talking about this more once > 1.5 is out the door. > > > > ,Wil > > > > *From:* Bradley Holt [mailto:[EMAIL PROTECTED] > *Sent:* Tuesday, February 05, 2008 7:04 AM > *To:* Elliot Anderson > *Cc:* Simone Carletti; fw-general@lists.zend.com > *Subject:* Re: [fw-general] ZF Packaging > > > > Elliot, > > The main reason that mootools does this, in my understanding, is so that > it can give you one JavaScript file to be included in your web page with > only the components you need. There are performance advantages to this since > you are only requiring the user's browser to get the JavaScript components > it will need, not all of mootols. With Zend Framework, there is no > performance advantage to only installing a handful of components. My > understanding is that the performance hit comes when you require or include > the component, not from it simply sitting on your web server. In other > words, the main advantage of the pick-what-you-want download system doesn't > apply when it comes to Zend Framework. The only advantage I can see is > storage space, but have there been any complaints about that with Zend > Framework? > > Thanks, > Bradley > > On Feb 5, 2008 6:26 AM, Elliot Anderson <[EMAIL PROTECTED]> wrote: > > I'm a fan of the pick-what-you-want download system that Moo Tools has. > > http://mootools.net/download > > > > > On Jan 29, 2008 6:04 AM, Simone Carletti <[EMAIL PROTECTED]> wrote: > > On Jan 28, 2008 3:57 PM, Richard Thomas <[EMAIL PROTECTED]> wrote: > > zfdev.com is a community supported project that never really took off, > It was never an "official" repository though. > > > > Sorry Richard, > my misunderstanding. :) > > Thanks for pointing it out. > > Simone > > > > > > > -- > Bradley Holt > [EMAIL PROTECTED] > -- Bradley Holt [EMAIL PROTECTED]
RE: [fw-general] ZF Packaging
I generally like mootools’ and other JS libraries simplistic dependency model (AFAIC tell, the core lib is the only dependency allowed, so a general-purpose packaging system with tracking across full dependency graphs is not necessary). If we were to start distributing parts of ZF in a piecemeal fashion, I think that we would also see great benefit from a few basic rules aimed at drastically simplifying dependency management. While there is no immediate and significant runtime advantage that I can see here, we are interested in- and have been discussing- distributing at least one ‘lean and mean’ archive. There are several reasons for this, including lower load on our servers and- taking off my perfectly logical developer hat and putting on a more realistic marketing hat ;)- the fact that many developers and reviewers consider distribution size to be an important dimension on which to judge a framework. I don’t necessarily think that distribution size is a good indication of anything for a server-side framework beyond what you *can’t* expect to be included, such as sizable locale files which are very useful to our many international users but that add a MB or two to the current distribution of ZF (Thomas has done an excellent job getting these as small as possible while maintaining everything that makes them so useful in the first place), but I do think that the ‘download only what you need’ distribution mechanism is both technically and philosophically compatible with ZF in its current state. We’ll probably be talking about this more once 1.5 is out the door. ,Wil From: Bradley Holt [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 05, 2008 7:04 AM To: Elliot Anderson Cc: Simone Carletti; fw-general@lists.zend.com Subject: Re: [fw-general] ZF Packaging Elliot, The main reason that mootools does this, in my understanding, is so that it can give you one JavaScript file to be included in your web page with only the components you need. There are performance advantages to this since you are only requiring the user's browser to get the JavaScript components it will need, not all of mootols. With Zend Framework, there is no performance advantage to only installing a handful of components. My understanding is that the performance hit comes when you require or include the component, not from it simply sitting on your web server. In other words, the main advantage of the pick-what-you-want download system doesn't apply when it comes to Zend Framework. The only advantage I can see is storage space, but have there been any complaints about that with Zend Framework? Thanks, Bradley On Feb 5, 2008 6:26 AM, Elliot Anderson <[EMAIL PROTECTED]> wrote: I'm a fan of the pick-what-you-want download system that Moo Tools has. http://mootools.net/download On Jan 29, 2008 6:04 AM, Simone Carletti <[EMAIL PROTECTED]> wrote: On Jan 28, 2008 3:57 PM, Richard Thomas <[EMAIL PROTECTED]> wrote: zfdev.com is a community supported project that never really took off, It was never an "official" repository though. Sorry Richard, my misunderstanding. :) Thanks for pointing it out. Simone -- Bradley Holt [EMAIL PROTECTED]
Re: [fw-general] ZF Packaging
Elliot, The main reason that mootools does this, in my understanding, is so that it can give you one JavaScript file to be included in your web page with only the components you need. There are performance advantages to this since you are only requiring the user's browser to get the JavaScript components it will need, not all of mootols. With Zend Framework, there is no performance advantage to only installing a handful of components. My understanding is that the performance hit comes when you require or include the component, not from it simply sitting on your web server. In other words, the main advantage of the pick-what-you-want download system doesn't apply when it comes to Zend Framework. The only advantage I can see is storage space, but have there been any complaints about that with Zend Framework? Thanks, Bradley On Feb 5, 2008 6:26 AM, Elliot Anderson <[EMAIL PROTECTED]> wrote: > I'm a fan of the pick-what-you-want download system that Moo Tools has. > > http://mootools.net/download > > > > > On Jan 29, 2008 6:04 AM, Simone Carletti <[EMAIL PROTECTED]> wrote: > > > On Jan 28, 2008 3:57 PM, Richard Thomas <[EMAIL PROTECTED]> wrote: > > > > > zfdev.com is a community supported project that never really took off, > > > It was never an "official" repository though. > > > > > > > Sorry Richard, > > my misunderstanding. :) > > > > Thanks for pointing it out. > > > > Simone > > > > -- Bradley Holt [EMAIL PROTECTED]
Re: [fw-general] ZF Packaging
I'm a fan of the pick-what-you-want download system that Moo Tools has. http://mootools.net/download On Jan 29, 2008 6:04 AM, Simone Carletti <[EMAIL PROTECTED]> wrote: > On Jan 28, 2008 3:57 PM, Richard Thomas <[EMAIL PROTECTED]> wrote: > > > zfdev.com is a community supported project that never really took off, > > It was never an "official" repository though. > > > > Sorry Richard, > my misunderstanding. :) > > Thanks for pointing it out. > > Simone >
Re: [fw-general] ZF Packaging
On Jan 28, 2008 3:57 PM, Richard Thomas <[EMAIL PROTECTED]> wrote: > zfdev.com is a community supported project that never really took off, > It was never an "official" repository though. > Sorry Richard, my misunderstanding. :) Thanks for pointing it out. Simone
RE: [fw-general] ZF Packaging
Thanks for bringing that up, Simone. That page is out-of-date at this point and it needs to be updated. I haven't gotten to this yet because I wanted to replace it with a real FAQ that is current but I haven't found the time. I will try to do something with that page- possibly just archive it- later today. ,Wil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simone Carletti Sent: Sunday, January 27, 2008 6:07 AM To: Wil Sinclair Cc: fw-general@lists.zend.com Subject: Re: [fw-general] ZF Packaging 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: fw-general@lists.zend.com 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 wro
Re: [fw-general] ZF Packaging
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: fw-general@lists.zend.com > > > > > > > > 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: > >
Re: [fw-general] ZF Packaging
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:* fw-general@lists.zend.com > > *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 le
RE: [fw-general] ZF Packaging
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: fw-general@lists.zend.com > > 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 > > existen
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: fw-general@lists.zend.com 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 in
Re: [fw-general] ZF Packaging
Good to know Wil,
My ideal syntax would be CLI commands along these lines.
zfw install [version] [--date=date]
zfw install (install latest stable, say 1.5)
zfw install snapshot --date=20080123
zfw install svn
zfw install 1.0.0 (specific versions)
zfw install 1.0.5
zfw update [version] (apply security patches to a specific version or
all versions, allowing for backported security fixes without application
upgrades)
These commands would create a very simply directory structure
/usr/share/php/ZendFramework/ZendFramework-1.5
/usr/share/php/ZendFramework/ZendFramework-snapshot-20080123
/usr/share/php/ZendFramework/ZendFramework-svn
/usr/share/php/ZendFramework/ZendFramework-1.0.0
/usr/share/php/ZendFramework/ZendFramework-1.0.5
Which would then be bootstrapped using something similar to the following
$fwVersion = '1.0.0';
$fwPath = '/usr/share/php/ZendFramework';
$paths = array(
$fwPath . DIRECTORY_SEPARATOR . 'ZendFramework-'. $fwVersion .
DIRECTORY_SEPARATOR. 'library',
get_include_path()
);
set_include_path(implode(PATH_SEPARATOR, $paths));
require_once('Zend/Loader.php');
It's basic, but therein lies the simplicity. One thing to note is that,
very soon, the framework is going to have to come up with a plan for
security patches that doesn't require downloading the latest tarball,
and updating ones application to a new version.
K
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:* fw-general@lists.zend.com
*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 all
RE: [fw-general] ZF Packaging
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: fw-general@lists.zend.com 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 w
Re: [fw-general] ZF Packaging
ge. 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:* fw-general@lists.zend.com >>>> *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
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:* fw-general@lists.zend.com *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 eme
Re: [fw-general] ZF Packaging
Bryce Lohr wrote: Having a PEAR channel would seem to me (from an end-user perspective) better than having to learn an additional CLI tool that essentially does the same thing PEAR already does: put some PHP code on my system. As Paddy mentioned in another post, PEAR has quite a bit of functionality. Many PHP developers are already familiar with it. What would a ZF-specific tool need to do that PEAR could not do already? If there's some specific requirement that PEAR can't meet, then that seems like a good reason to consider a custom tool. If there is some specific requirement PEAR can't meet then there is an alternative of contributing the needed modifications back to PEAR. All-in-all it's what open source is all about. I'm in favor of using long established standards and code reuse rather tahn next proprietary release management platform. I vote for PEAR. Also, none of this should preclude keeping the existing tarball/zip download. Exactly. -- Michał Minicki aka Martel Valgoerad | [EMAIL PROTECTED] | http://aie.pl/martel.asc =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Idleness is not doing nothing. Idleness is being free to do anything." -- Floyd Dell
Re: [fw-general] ZF Packaging
Having a PEAR channel would seem to me (from an end-user perspective) better than having to learn an additional CLI tool that essentially does the same thing PEAR already does: put some PHP code on my system. As Paddy mentioned in another post, PEAR has quite a bit of functionality. Many PHP developers are already familiar with it. What would a ZF-specific tool need to do that PEAR could not do already? If there's some specific requirement that PEAR can't meet, then that seems like a good reason to consider a custom tool. Also, none of this should preclude keeping the existing tarball/zip download. Best regards, Bryce Lohr 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]] Sent: Tuesday, January 22, 2008 2:13 PM To: fw-general@lists.zend.com 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 - Original Message From: Wil Sinclair <[EMAIL PROTECTED]> To: fw-general@lists.zend.com 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
Re: [fw-general] ZF Packaging
I second that. Having a PEAR channel is just another way to get the Zend Framework not the only one. My company built a custom framework above the ZF and we plan do distribute it through a PEAR channel for simplicity. Adding the ZF as a requirement instead of having to pack it with our package would really ease our work. Jean-Marc Kanopée - Développement Informatique Durable 56 rue de Saint André 59800 Lille Tél : 03 20 74 61 25 Portable : 06 88 56 50 79 Fax : 09 59 77 04 28 Web : http://www.kanopee.net/
Re: [fw-general] ZF Packaging
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:* fw-general@lists.zend.com >> *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 - >>
Re: [fw-general] ZF Packaging
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:* fw-general@lists.zend.com > *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: fw-general@lists.zend.com > 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 > > > >
Re: [fw-general] ZF Packaging
-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] *Sent:* Tuesday, January 22, 2008 2:13 PM *To:* fw-general@lists.zend.com *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]> <mailto:[EMAIL PROTECTED]> To: fw-general@lists.zend.com <mailto:fw-general@lists.zend.com> 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
RE: [fw-general] ZF Packaging
I would prefer not to use PEAR. Seems like a silver bullet solution to me... I have an anal-retentive need to know exactly what is going on in my projects. Doesn't mean that PEAR doesn't work for the rest of you, but I would like to continue to download it, unpack it and move it myself. On Tue, 22 Jan 2008 16:01:05 -0800, "Wil Sinclair" <[EMAIL PROTECTED]> 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] > Sent: Tuesday, January 22, 2008 2:13 PM > To: fw-general@lists.zend.com > 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]> <mailto:[EMAIL PROTECTED]> > To: fw-general@lists.zend.com > 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 > > > > >
RE: [fw-general] ZF Packaging
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] Sent: Tuesday, January 22, 2008 2:13 PM To: fw-general@lists.zend.com 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]> <mailto:[EMAIL PROTECTED]> To: fw-general@lists.zend.com 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
RE: [fw-general] ZF Packaging
Microsoft rip-off for those who have worked with Visual C++ (http://support.microsoft.com/kb/166474) #define WIN32_LEAN_AND_MEAN We use it in PHP J Andi From: Pádraic Brady [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 22, 2008 2:08 PM To: Wil Sinclair Cc: Zend Framework General Subject: Re: [fw-general] ZF Packaging 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]> To: fw-general@lists.zend.com 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
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 - Original Message From: Wil Sinclair <[EMAIL PROTECTED]> To: fw-general@lists.zend.com 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
Re: [fw-general] ZF Packaging
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 - Original Message From: Wil Sinclair <[EMAIL PROTECTED]> To: fw-general@lists.zend.com 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
[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
