So, not being one to leave important issues hanging, I’ll let all of
you in on our thinking WRT PEAR here at Zend. While PEAR is a great
packaging and distribution tool, many of our users really appreciate
the simple tarball installation we currently offer; this is something
we get a lot of positive feedback on. Suffice it to say, whatever we
do vis a vis PEAR is unlikely to entirely replace the current method
of distribution.
At this point, we don’t see enough value in establishing a PEAR
channel and packaging ZF for PEAR to commit Zend resources to do this
for every release (remember we’re trying to release functionality
early and often, so release overhead must be kept to a minimum). That
said, there are no terms in the licensing of ZF that prevent another
party from packaging ZF for PEAR as they see fit and creating a PEAR
channel. We could even consider hosting this if someone makes the
significant commitment to keep it current and we can agree on the
packaging. That would be a discussion for **after** someone has shown
that they are dedicated to this project (probably by establishing an
existing PEAR package(s) for a few releases) and has put together a
proposal for us to consider.
In any case, there are- and almost surely will always be- those users
who won’t want to use PEAR, and we will continue to make the
installation process simple for them. At this point it seems that the
best option is a tarball with possibly some CLI support for
downloading some optional code/data. We do appreciate the
distribution/versioning/dependency management issues in general
packaging systems, and we certainly wouldn’t take on something this
ambitious at this point. We’ll only add support for minimal
distribution capabilities to the CLI if we can simplify requirements
for a ZF-specific setup in a way that doesn’t have nasty side effects
or gets us in to dependency hell.
Hope that sheds some light on the issue from our side.
,Wil
*From:* Kevin McArthur [mailto:[EMAIL PROTECTED]
*Sent:* Wednesday, January 23, 2008 9:11 AM
*To:* Pádraic Brady
*Cc:* [email protected]
*Subject:* Re: [fw-general] ZF Packaging
No time for a big rant today,
1. No versioned/split sub-packages. (decided long ago)
2. Versioned paths in pear breaks pear standard operating method. May
be confusing for that reason. Pear Upgrade ZendFramework _must_ be
avoided if it will change files to newer functional versions.
3. How would you deploy security fixes to existing version releases.
4. There has been talk/work on a CLI tool for bootstrapping anyway,
just seems installation would be a natural extension as one command
could download/install and bootstrap to prevent any pathing problems.
K
Pádraic Brady wrote:
To remark on some of the PEAR FUD.
PEAR doesn't remove the ability to download, decompress, copy and otherwise
manually manage the source code - essentially it just takes a default action
of downloading, decompressing, and copying into the /php/pear directory
which should already be present on the PHP include_path in php.ini which
alleviates one more include_path search for those getting a bit worried
about having >2. The proposed download archives for Core/Extras/etc. can
merrily continue their existence. They wouldn't even share the same
subdomain...
Does it preclude path versioning? I can script an entire PEAR system into
existence using Phing based on any array of preferred version numbers -
especially since PEAR does allow you to force installation of one specific
version irrespective of it's status or age. Last I checked the basic PEAR
installed in under 5 minutes. There is also version compatibility control
built into PEAR since you can set a preferred-version on all dependencies
package by package. This means control over specific preferred versions for
any remote system is a doddle. The only manual intervention would be
changing the include_path for the application...
Finally, the ZF is a componentised framework - not a fragile stack of cards
that will fall apart in PEAR - everyone did quite a good job of ensuring
classes/components are decoupled. I would agree that at a minimum there
would have to be a Core package of say the MVC components to form the basic
installation base for immediate use - everything else could be made a
self-contained package available across PEAR, with aggregated commands to
install specific "bundles" of packages (perhaps reflecting the proposed
download split). Then one could:
pear channel-discover pear.framework.zend.com
pear install zend/Zend_Core
pear install zend/Zend_Services_Flickr
pear install --force zend/Zend_Pdf-1.1.2
Not saying the PEAR route is any easier than whatever CLI option Will is
considering - but PEAR does have the advantage of being in this distribution
business for long enough to learn substantial lessons. The main disadvantage
is packaging everything to start with - not a simple task and something for
whoever maintains the current ZF build.xml to look into. At the moment for
Phing, I'm leaning on work from Travis Swicegood who wrote a lean and mean
PEAR packaging task for Phing over on pear.domain51.com.
Best regards,
Paddy
Karl Katzke wrote:
A better example might be Python Eggs. You can unpack them to a directory
of
your choosing using a simple CLI-bootstrap file.
Symfony does use Pear, but Symfony is not very shared-hosting friendly --
and Zend *is* shared-hosting friendly, which is something that I would
very
much like to see the community maintain.
-K
On Jan 22, 2008 6:12 PM, Kevin McArthur <[EMAIL PROTECTED]> <mailto:[EMAIL
PROTECTED]> wrote:
-1 from me on this idea.
Pear updating something as fragile as the framework could cause all
kinds
of serious problems for sites using it as a shared library.
It would be better to have a cli tool for framework installation.. a web
installer like go-pear would probably be a better format for this.
I'd also still continue to advocate when using a shared library approach
that people use a versioned installation path like
/usr/share/php/ZendFramework/ZendFramework-1.5 such that bootstrap files
can pick their target versions explicitly.
Kevin
Wil Sinclair wrote:
Actually, I'm a bit ignorant since I'm a relative PHP newbie, but let
me
turn that question around- why would a PEAR channel be a good way to
distribute ZF? That is, considering the current ZF installation is
basically
download, decompress, and update include path, what does PEAR bring to
the
table that I'm missing?
,Wil
*From:* Bryce Lohr
[mailto:[EMAIL PROTECTED]<[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]>]
*Sent:* Tuesday, January 22, 2008 2:13 PM
*To:* [email protected] <mailto:[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]> <mailto:[EMAIL PROTECTED]> <[EMAIL
PROTECTED]> <mailto:[EMAIL PROTECTED]>
To: [email protected] <mailto:[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
