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