No time for a big rant today,
1. No versioned/split sub-packages. (decided long ago)
2. Versioned paths in pear breaks pear standard operating method. May be
confusing for that reason. Pear Upgrade ZendFramework _must_ be avoided
if it will change files to newer functional versions.
3. How would you deploy security fixes to existing version releases.
4. There has been talk/work on a CLI tool for bootstrapping anyway, just
seems installation would be a natural extension as one command could
download/install and bootstrap to prevent any pathing problems.
K
Pádraic Brady wrote:
To remark on some of the PEAR FUD.
PEAR doesn't remove the ability to download, decompress, copy and otherwise
manually manage the source code - essentially it just takes a default action
of downloading, decompressing, and copying into the /php/pear directory
which should already be present on the PHP include_path in php.ini which
alleviates one more include_path search for those getting a bit worried
about having >2. The proposed download archives for Core/Extras/etc. can
merrily continue their existence. They wouldn't even share the same
subdomain...
Does it preclude path versioning? I can script an entire PEAR system into
existence using Phing based on any array of preferred version numbers -
especially since PEAR does allow you to force installation of one specific
version irrespective of it's status or age. Last I checked the basic PEAR
installed in under 5 minutes. There is also version compatibility control
built into PEAR since you can set a preferred-version on all dependencies
package by package. This means control over specific preferred versions for
any remote system is a doddle. The only manual intervention would be
changing the include_path for the application...
Finally, the ZF is a componentised framework - not a fragile stack of cards
that will fall apart in PEAR - everyone did quite a good job of ensuring
classes/components are decoupled. I would agree that at a minimum there
would have to be a Core package of say the MVC components to form the basic
installation base for immediate use - everything else could be made a
self-contained package available across PEAR, with aggregated commands to
install specific "bundles" of packages (perhaps reflecting the proposed
download split). Then one could:
pear channel-discover pear.framework.zend.com
pear install zend/Zend_Core
pear install zend/Zend_Services_Flickr
pear install --force zend/Zend_Pdf-1.1.2
Not saying the PEAR route is any easier than whatever CLI option Will is
considering - but PEAR does have the advantage of being in this distribution
business for long enough to learn substantial lessons. The main disadvantage
is packaging everything to start with - not a simple task and something for
whoever maintains the current ZF build.xml to look into. At the moment for
Phing, I'm leaning on work from Travis Swicegood who wrote a lean and mean
PEAR packaging task for Phing over on pear.domain51.com.
Best regards,
Paddy
Karl Katzke wrote:
A better example might be Python Eggs. You can unpack them to a directory
of
your choosing using a simple CLI-bootstrap file.
Symfony does use Pear, but Symfony is not very shared-hosting friendly --
and Zend *is* shared-hosting friendly, which is something that I would
very
much like to see the community maintain.
-K
On Jan 22, 2008 6:12 PM, Kevin McArthur <[EMAIL PROTECTED]> wrote:
-1 from me on this idea.
Pear updating something as fragile as the framework could cause all kinds
of serious problems for sites using it as a shared library.
It would be better to have a cli tool for framework installation.. a web
installer like go-pear would probably be a better format for this.
I'd also still continue to advocate when using a shared library approach
that people use a versioned installation path like
/usr/share/php/ZendFramework/ZendFramework-1.5 such that bootstrap files
can pick their target versions explicitly.
Kevin
Wil Sinclair wrote:
Actually, I'm a bit ignorant since I'm a relative PHP newbie, but let me
turn that question around- why would a PEAR channel be a good way to
distribute ZF? That is, considering the current ZF installation is
basically
download, decompress, and update include path, what does PEAR bring to
the
table that I'm missing?
,Wil
*From:* Bryce Lohr
[mailto:[EMAIL PROTECTED]<[EMAIL PROTECTED]>]
*Sent:* Tuesday, January 22, 2008 2:13 PM
*To:* [email protected]
*Subject:* Re: [fw-general] ZF Packaging
I second the request for PEAR channel. Is there any reason why that would
not be a good way to distribute the framework?
Regards,
Bryce Lohr
Pádraic Brady wrote:
*Hi Will,
It sounds good - an optional lean package would frighten off far less
prospective users who have heard tales about HDD's dying from the strain
of
downloading the ZF ;).
I would still like to see a PEAR channel emerge at some point though -
that may be a fanciful concept but I gather from the last paragraph
something along those lines is under consideration?
Hope someone comes up with colourful names for these variants!
Best regards,
Paddy*
*Pádraic Brady
**http://blog.astrumfutura.com
http://www.patternsforphp.com
OpenID Europe Foundation <http://www.openideurope.eu/>*
----- Original Message ----
From: Wil Sinclair <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
To: [email protected]
Sent: Tuesday, January 22, 2008 8:36:39 PM
Subject: [fw-general] ZF Packaging
As part of the 1.5 release process, we've been reviewing the size of our
distribution package and what contributes the most weight. We've
determined that there are a few 'heavyweights' that we currently have in
the zips/tarballs that many- if not most- users will never need. These
include the unit tests, the demos, and the locale files (currently
consuming ~8MB uncompressed on my hdd :O). With these components, the
1.0.3 release is ~5.3MB compressed on my hdd. We would like to
distribute, starting with the 1.5 RC1, a 'lean and mean' ZF package
alongside the 'everything' package. The 'lean and mean' package would
not contain the tests, demos, locale files, or extras. 'Everything'
would include, well, everything- even docs in html format. To facilitate
access to the omissions from the 'lean and mean' release, we would
provide a download action for the CLI tool so they can be retrieved and
installed in the correct place with a single command.
Thomas can give more details about how the locale-aware components would
behave in this proposal.
Thoughts?
Thanks.
,Wil
