Discussion Time: In ZF2, Where Do Things Go?

[Wil Moore III]

>
> As for the debugging argument, again this isn't complicated. It either
> loads or it doesn't. Its way early in the page setup that its immediately
> obvious if Zend_Application cant be found. Should be no complex debugging if
> you get the path wrong. If you want to be sure of a wrong path + an existing
> zfw on the include path, you could add the version check I spec'd in my
> previous email... but i think thats pushing it.
>

I agree with this. Not super complicated, especially if you have a fairly
rich and re-useable bootstrapping process (e.g. common entry point for web
app, cli, web services, etc.)

 ... duplicating libraries also is not standard across the software
> development world -- everyone uses shared libraries. Imagine if every app
> shipped its own copies of libc.so!
>

This is a pretty sweeping statement and isn't actually representative of
what people are actually doing. A few examples:


   1. Ruby / Rails (freezing gems and the latest practice is to use Bundler
   to pull gems into the vendor cache) -- There is a note on the bundler site
   that this is not recommended listing size as a deterrent. In practice, that
   is a silly reason to not do this and a quick search for "gem freeze" or
   "rails gem freeze" or "bundle lock" (deprecated in favor of "bundle pack").
   2. NuGet -- for .NET. The installer by default pulls dependencies into
   your solution.
   3. Maven -- dependencies are downloaded once and only updated
   periodically. You can force updates to happen only on-demand by updating
   your pom setting updatePolicy to never.
   4. SBT (same as Maven in that it can use the pom file but uses IVY behind
   the scenes)


Obviously every project has its own requirements but I would imagine that
most projects would not want to have to deal with global dependencies but
rather deal with them local to the project at hand. Obviously _your_
use-case is a bit difference, but that doesn't necessarily mean that the
entire landscape looks like this :)

[padraicb]

Beginning to regret switching subject lines - can we use the same one? ;)

Every problem has a solution. Need to get Library A (versions 1 and 2) onto a
server somewhere? Go find one. PHP has countless numbers of them. If we're going
to start arguing over something as basic as loading up multiple versions of one
library onto one filesystem, then we've already lost the plot completely. It is
a valid problem. The fact is, PHP does not have one widely adopted solution for
this - there go newcomers. They will run around like headless chickens wondering
what the heck that's all about and driving anyone offering support up the
nearest wall. Does this make the approach bad? I hope not - otherwise I have a
lot of applications in dire need of a better programmer...

The plot has diverged from why this confusion exists, and the reason is very
simple. PHP has PEAR. PEAR does not support this in a simple straightforward
manner (neither does Pyrus). Applications shouldn't even NEED to go manage this.
An application should just send over a version constraint and stop right there.
Try installing Ruby. It has a packaging system called Rubygems and a fabulous
tool called Bundler to allow applications carry around their version constraints
for easy deployment. Combined they make PHP's mish mash of conflicting
strategies for library management in a shared, or shared isolated, environment
look like a complicated and completely unnecessary Hell. Using anything except
gems + Bundler (and git - obviously!) in Ruby is like stating the Sun is blue
with pink dots - crazy talk.

Having an insufficient tool in PHP is not the basis of criticising a common
approach to managing dependencies. Wrong way around! Criticise the tool - why
does it not support a common approach? What can it do to offer that support?
What are the specific reasons for its choices? I don't have those answers. I've
asked them before, but nobody who answered had a clue either. So PHP developers
will continue to adopt differing solutions and argue over which one is the best
and where the responsibility of every facet should lie. Oh, and ignore PEAR.

Paddy

 Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team





________________________________
From: Matthew Weier O'Phinney <[hidden email]>
To: [hidden email]
Sent: Wed, June 1, 2011 6:06:59 PM
Subject: Re: [zf-contributors] How to package ZF2

-- Kevin McArthur <[hidden email]> wrote
(on Wednesday, 01 June 2011, 08:22 AM -0700):

> On 11-06-01 07:28 AM, Matthew Weier O'Phinney wrote:
> >-- Kevin McArthur<[hidden email]>  wrote
> >(on Tuesday, 31 May 2011, 03:43 PM -0700):
> >>This claim is not accurate. I have been doing this since ZFW came
> >>out using the well known and well described methods (methods that
> >>are published and widely used). I have _never_ once run into a class
> >>resolution issue or picked up a wrong version. It is simply not
> >>possible to occur with a proper bootstrap which is both simple and
> >>easily defined.
> >The claim is inaccurate for *you*. *You* have not had problems. That
> >does not count as empirical evidence.
> I also published it in my book, which is widely read and deployed. I
> receive questions on a regular basis from readers. No one has ever
> emailed me a question on this topic.

I'm not questioning that. I'm saying that just because *you* haven't had
support issues, that doesn't mean *others* have not, either.

> > I comb through the mailing lists, twitter, various forums, and more
> > regularly -- to see where the problem areas are. Many things that
> > come easy to me due to my experience are simply hard for other
> > developers; we all come from different backgrounds and experience.
> This is why I take a cut-n-paste rather than a
> figure-it-out-yourself approach to this.

I really don't know what you're implying by this.

My experience with cut-and-paste solutions is:

* Developers that follow them often don't take the time to understand
   what is being done, and why it works.
* Which means that when something breaks, they become quite vocal about
   the solution not working.
* If the solution relies on cut-and-paste to mask complexity, this
   makes education harder.

I'm not advocating a "figure-it-out-yourself" or "RTFM" approach. I'm
saying that the core of the framework should be easily approachable,
learnable, and comprehensible (versus comprehensive).

Clearly, our experience differs widely with what works and what doesn't
in that regard. I'm thinking we need to do some polls around this topic,
to be honest.

> > I have had to answer quite a number of support questions regarding the
> > practice of parallel versioned installs and system-level installs. In
> > fact, one large reason the quick start recommends having the ZF library
> > linked into the project is due to the number of questions myself, others
> > on my team, and community contributors have had to answer on the
> > subject. (The other is due to the complexity of explaining the
> > include_path, which, while an easy topic for experienced developers, is
> > really, really hard for newcomers to PHP and/or ZF to learn).
> If developers use pear, and try to install multiple versions all
> about the system, yes, they will have problems. They will probably
> have lots of problems with 'pyrus'es versioned installs. Thats
> complicated custom syntax.

I'm not talking about PEAR or Pyrus here. I'm talking about having
shared ZF installs, either a single install on the include_path or
versioned installs such as you advocated in your email.

> The method I'm suggesting was pioneered back in the original ZF1
> development cycle days and _used_ to be the standard. There weren't
> issues with it then either. If you can extract a file, you can use
> versioned installs reliably.
> > So, while a "proper bootstrap" may be simple and easy to define for
> > some, it's not for others, and often poses new questions: where exactly
> > was ZF installed? Are there parallel versions? Who linked "latest", and
> > what does it link to? What happens if the directory is misnamed? Which
> > autoloader is used? What happens if I have multiple ZF versions on my
> > include_path?
> This is why its boiled down to two constants.

Why have *any* constants? That's a serious question, actually. What if
we could get away with not using *any*?

As an example, I'm planning on including a .classmap.php file with ZF2.
What if we also had an _autoload.php file that consumed it as part of a
simple autoloader? Suddenly, it becomes as easy as:

    include "path/to/zf-install/perhaps-even-version/_autoload.php";

    // start doing stuff


> An installed path and a version. Interestingly, if the path cannot be
> found, the site puts up a really obvious cannot find zend_loader
> error.

This is a good point. The problem is that if you have display_errors
off, or you're not logging errors, or you're relatively new to PHP, it's
really hard to debug. (Trust me on this one -- autoload functionality in
ZF1 has been a pain due to trying to cater to a wide range of
abilities.)

> If you wanted to be extra certain, we could add a check to the
> bootstrap to ensure the defined version is the loaded version, but
> I've never seen the need for such a check. That would look like
>
> if(!version_compare(ZFW_VERSION, Zend_Version::VERSION, '==')) {
> throw new RuntimeException('Defined version is not loaded version');
> } which could be expanded to check latest too if needed... but that
> would require some sort of entropy entry point to be fast and
> efficient.

That's actually a really nice idea, and a good argument for the
constant. I'd like to see it encapsulated -- we could likely encapsulate
it in Zend_Version itself:

    Zend_Version::validateVersion(ZFW_VERSION, Zend_Version::ALLOW_SAME_MINOR);

(It wouldn't technically need a constant, actually...)

> > When I deploy to my shared host (or server with multiple sites), how do
> > I ensure the appropriate version of ZF is available? What happens if one
> > site upgrades to the latest on the same minor release series -- and my
> > site using the same series somehow now breaks?
> >
> HUH? If the shared host installs a new minor release, your site wont
> pick it up until you specify it directly. Nothing gets automatically
> picked up -- which while it could leave your site using an older
> ZFW, it is by design for QA reasons.

I was thinking along the lines of specifying just a minor version, not a
specific version; e.g., using "1.11" instead of "1.11.3". That's where
that question arises.

> I think you're way overblowing the case against version-ed installs
> to make it work with already-planned distribution methods.

Bad assumption, actually. As I've noted, there are reasons the quick
start doesn't use versioned installs, and it's due to support/education
issues. In talking to the folks behind Pyrus, they've run into the same
issues, which is why they're not planning on offering it (and they, too
have had many requests for it, and not just from ZF folks).

> This is neither complicated nor unreliable. Its tested, widely
> deployed and simple to understand. Developers who don't know what a
> include path are simple copy over the index.php set two constants,
> (the right version and the right framework path) and customize their
> application.ini. If they can't handle that, they have no business
> developing a ZFW application and should be using Wordpress.

I agree that it's simple in concept. And I think we can continue to
support it in the autoloader and potentially within our documentation;
since you'll always be able to simply download a tarball/zip and inflate
it, you will always be able to do this style.

I'm just not 100% sure we should have it as a requirement for
per-component or full-framework distribution via a CLI/web-based
installer, particularly if dropping that requirement means we don't need
to write our own installer.

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[padraicb]

While on the topic, I'm of the belief that nothing particular pushes its way
into the perfection range. Pyrus would be better than PEAR, but it's also the
option with the least adoption (we all know whatever Symfony invents will be
adopted like wildfire) and I've yet to see any sort of timetable on when it can
be expected to be considered stable. If I were a betting man, I'd lay some money
on PEAR. It's stable, widely adopted, well known, and the devil we know how to
manipulate. That said, I don't it drastically changing the status quo of how we
already use, install and deploy ZF1 apps - it's just one other option to grab
ZF2 conveniently so I'd prefer we didn't hype it up all the way up as THE way to
get ZF2.

Paddy

 Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team





________________________________
From: Pádraic Brady <[hidden email]>
To: Matthew Weier O'Phinney <[hidden email]>
Cc: Zend Framework Contributors <[hidden email]>
Sent: Wed, June 1, 2011 8:12:49 PM
Subject: Re: [zf-contributors] How to package ZF2

Beginning to regret switching subject lines - can we use the same one? ;)

Every problem has a solution. Need to get Library A (versions 1 and 2) onto a
server somewhere? Go find one. PHP has countless numbers of them. If we're going

to start arguing over something as basic as loading up multiple versions of one
library onto one filesystem, then we've already lost the plot completely. It is
a valid problem. The fact is, PHP does not have one widely adopted solution for
this - there go newcomers. They will run around like headless chickens wondering

what the heck that's all about and driving anyone offering support up the
nearest wall. Does this make the approach bad? I hope not - otherwise I have a
lot of applications in dire need of a better programmer...

The plot has diverged from why this confusion exists, and the reason is very
simple. PHP has PEAR. PEAR does not support this in a simple straightforward
manner (neither does Pyrus). Applications shouldn't even NEED to go manage this.

An application should just send over a version constraint and stop right there.
Try installing Ruby. It has a packaging system called Rubygems and a fabulous
tool called Bundler to allow applications carry around their version constraints

for easy deployment. Combined they make PHP's mish mash of conflicting
strategies for library management in a shared, or shared isolated, environment
look like a complicated and completely unnecessary Hell. Using anything except
gems + Bundler (and git - obviously!) in Ruby is like stating the Sun is blue
with pink dots - crazy talk.

Having an insufficient tool in PHP is not the basis of criticising a common
approach to managing dependencies. Wrong way around! Criticise the tool - why
does it not support a common approach? What can it do to offer that support?
What are the specific reasons for its choices? I don't have those answers. I've
asked them before, but nobody who answered had a clue either. So PHP developers
will continue to adopt differing solutions and argue over which one is the best
and where the responsibility of every facet should lie. Oh, and ignore PEAR.

Paddy

Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team





________________________________
From: Matthew Weier O'Phinney <[hidden email]>
To: [hidden email]
Sent: Wed, June 1, 2011 6:06:59 PM
Subject: Re: [zf-contributors] How to package ZF2

-- Kevin McArthur <[hidden email]> wrote
(on Wednesday, 01 June 2011, 08:22 AM -0700):

> On 11-06-01 07:28 AM, Matthew Weier O'Phinney wrote:
> >-- Kevin McArthur<[hidden email]>  wrote
> >(on Tuesday, 31 May 2011, 03:43 PM -0700):
> >>This claim is not accurate. I have been doing this since ZFW came
> >>out using the well known and well described methods (methods that
> >>are published and widely used). I have _never_ once run into a class
> >>resolution issue or picked up a wrong version. It is simply not
> >>possible to occur with a proper bootstrap which is both simple and
> >>easily defined.
> >The claim is inaccurate for *you*. *You* have not had problems. That
> >does not count as empirical evidence.
> I also published it in my book, which is widely read and deployed. I
> receive questions on a regular basis from readers. No one has ever
> emailed me a question on this topic.

I'm not questioning that. I'm saying that just because *you* haven't had
support issues, that doesn't mean *others* have not, either.

> > I comb through the mailing lists, twitter, various forums, and more
> > regularly -- to see where the problem areas are. Many things that
> > come easy to me due to my experience are simply hard for other
> > developers; we all come from different backgrounds and experience.
> This is why I take a cut-n-paste rather than a
> figure-it-out-yourself approach to this.

I really don't know what you're implying by this.

My experience with cut-and-paste solutions is:

* Developers that follow them often don't take the time to understand
   what is being done, and why it works.
* Which means that when something breaks, they become quite vocal about
   the solution not working.
* If the solution relies on cut-and-paste to mask complexity, this
   makes education harder.

I'm not advocating a "figure-it-out-yourself" or "RTFM" approach. I'm
saying that the core of the framework should be easily approachable,
learnable, and comprehensible (versus comprehensive).

Clearly, our experience differs widely with what works and what doesn't
in that regard. I'm thinking we need to do some polls around this topic,
to be honest.

> > I have had to answer quite a number of support questions regarding the
> > practice of parallel versioned installs and system-level installs. In
> > fact, one large reason the quick start recommends having the ZF library
> > linked into the project is due to the number of questions myself, others
> > on my team, and community contributors have had to answer on the
> > subject. (The other is due to the complexity of explaining the
> > include_path, which, while an easy topic for experienced developers, is
> > really, really hard for newcomers to PHP and/or ZF to learn).
> If developers use pear, and try to install multiple versions all
> about the system, yes, they will have problems. They will probably
> have lots of problems with 'pyrus'es versioned installs. Thats
> complicated custom syntax.

I'm not talking about PEAR or Pyrus here. I'm talking about having
shared ZF installs, either a single install on the include_path or
versioned installs such as you advocated in your email.

> The method I'm suggesting was pioneered back in the original ZF1
> development cycle days and _used_ to be the standard. There weren't
> issues with it then either. If you can extract a file, you can use
> versioned installs reliably.
> > So, while a "proper bootstrap" may be simple and easy to define for
> > some, it's not for others, and often poses new questions: where exactly
> > was ZF installed? Are there parallel versions? Who linked "latest", and
> > what does it link to? What happens if the directory is misnamed? Which
> > autoloader is used? What happens if I have multiple ZF versions on my
> > include_path?
> This is why its boiled down to two constants.

Why have *any* constants? That's a serious question, actually. What if
we could get away with not using *any*?

As an example, I'm planning on including a .classmap.php file with ZF2.
What if we also had an _autoload.php file that consumed it as part of a
simple autoloader? Suddenly, it becomes as easy as:

    include "path/to/zf-install/perhaps-even-version/_autoload.php";

    // start doing stuff


> An installed path and a version. Interestingly, if the path cannot be
> found, the site puts up a really obvious cannot find zend_loader
> error.

This is a good point. The problem is that if you have display_errors
off, or you're not logging errors, or you're relatively new to PHP, it's
really hard to debug. (Trust me on this one -- autoload functionality in
ZF1 has been a pain due to trying to cater to a wide range of
abilities.)

> If you wanted to be extra certain, we could add a check to the
> bootstrap to ensure the defined version is the loaded version, but
> I've never seen the need for such a check. That would look like
>
> if(!version_compare(ZFW_VERSION, Zend_Version::VERSION, '==')) {
> throw new RuntimeException('Defined version is not loaded version');
> } which could be expanded to check latest too if needed... but that
> would require some sort of entropy entry point to be fast and
> efficient.

That's actually a really nice idea, and a good argument for the
constant. I'd like to see it encapsulated -- we could likely encapsulate
it in Zend_Version itself:

    Zend_Version::validateVersion(ZFW_VERSION, Zend_Version::ALLOW_SAME_MINOR);

(It wouldn't technically need a constant, actually...)

> > When I deploy to my shared host (or server with multiple sites), how do
> > I ensure the appropriate version of ZF is available? What happens if one
> > site upgrades to the latest on the same minor release series -- and my
> > site using the same series somehow now breaks?
> >
> HUH? If the shared host installs a new minor release, your site wont
> pick it up until you specify it directly. Nothing gets automatically
> picked up -- which while it could leave your site using an older
> ZFW, it is by design for QA reasons.

I was thinking along the lines of specifying just a minor version, not a
specific version; e.g., using "1.11" instead of "1.11.3". That's where
that question arises.

> I think you're way overblowing the case against version-ed installs
> to make it work with already-planned distribution methods.

Bad assumption, actually. As I've noted, there are reasons the quick
start doesn't use versioned installs, and it's due to support/education
issues. In talking to the folks behind Pyrus, they've run into the same
issues, which is why they're not planning on offering it (and they, too
have had many requests for it, and not just from ZF folks).

> This is neither complicated nor unreliable. Its tested, widely
> deployed and simple to understand. Developers who don't know what a
> include path are simple copy over the index.php set two constants,
> (the right version and the right framework path) and customize their
> application.ini. If they can't handle that, they have no business
> developing a ZFW application and should be using Wordpress.

I agree that it's simple in concept. And I think we can continue to
support it in the autoloader and potentially within our documentation;
since you'll always be able to simply download a tarball/zip and inflate
it, you will always be able to do this style.

I'm just not 100% sure we should have it as a requirement for
per-component or full-framework distribution via a CLI/web-based
installer, particularly if dropping that requirement means we don't need
to write our own installer.

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[Kevin McArthur-2]

Seconded.

I'd support a go-zf.com or similar get-zend-tool-on-the-box script also.

--

K

On 11-06-01 12:24 PM, Pádraic Brady wrote:

> While on the topic, I'm of the belief that nothing particular pushes its way
> into the perfection range. Pyrus would be better than PEAR, but it's also the
> option with the least adoption (we all know whatever Symfony invents will be
> adopted like wildfire) and I've yet to see any sort of timetable on when it can
> be expected to be considered stable. If I were a betting man, I'd lay some money
> on PEAR. It's stable, widely adopted, well known, and the devil we know how to
> manipulate. That said, I don't it drastically changing the status quo of how we
> already use, install and deploy ZF1 apps - it's just one other option to grab
> ZF2 conveniently so I'd prefer we didn't hype it up all the way up as THE way to
> get ZF2.
>
> Paddy
>
>   Pádraic Brady
>
> http://blog.astrumfutura.com
> http://www.survivethedeepend.com
> Zend Framework Community Review Team
>
>
>
>
>
> ________________________________
> From: Pádraic Brady<[hidden email]>
> To: Matthew Weier O'Phinney<[hidden email]>
> Cc: Zend Framework Contributors<[hidden email]>
> Sent: Wed, June 1, 2011 8:12:49 PM
> Subject: Re: [zf-contributors] How to package ZF2
>
> Beginning to regret switching subject lines - can we use the same one? ;)
>
> Every problem has a solution. Need to get Library A (versions 1 and 2) onto a
> server somewhere? Go find one. PHP has countless numbers of them. If we're going
>
> to start arguing over something as basic as loading up multiple versions of one
> library onto one filesystem, then we've already lost the plot completely. It is
> a valid problem. The fact is, PHP does not have one widely adopted solution for
> this - there go newcomers. They will run around like headless chickens wondering
>
> what the heck that's all about and driving anyone offering support up the
> nearest wall. Does this make the approach bad? I hope not - otherwise I have a
> lot of applications in dire need of a better programmer...
>
> The plot has diverged from why this confusion exists, and the reason is very
> simple. PHP has PEAR. PEAR does not support this in a simple straightforward
> manner (neither does Pyrus). Applications shouldn't even NEED to go manage this.
>
> An application should just send over a version constraint and stop right there.
> Try installing Ruby. It has a packaging system called Rubygems and a fabulous
> tool called Bundler to allow applications carry around their version constraints
>
> for easy deployment. Combined they make PHP's mish mash of conflicting
> strategies for library management in a shared, or shared isolated, environment
> look like a complicated and completely unnecessary Hell. Using anything except
> gems + Bundler (and git - obviously!) in Ruby is like stating the Sun is blue
> with pink dots - crazy talk.
>
> Having an insufficient tool in PHP is not the basis of criticising a common
> approach to managing dependencies. Wrong way around! Criticise the tool - why
> does it not support a common approach? What can it do to offer that support?
> What are the specific reasons for its choices? I don't have those answers. I've
> asked them before, but nobody who answered had a clue either. So PHP developers
> will continue to adopt differing solutions and argue over which one is the best
> and where the responsibility of every facet should lie. Oh, and ignore PEAR.
>
> Paddy
>
> Pádraic Brady
>
> http://blog.astrumfutura.com
> http://www.survivethedeepend.com
> Zend Framework Community Review Team
>
>
>
>
>
> ________________________________
> From: Matthew Weier O'Phinney<[hidden email]>
> To: [hidden email]
> Sent: Wed, June 1, 2011 6:06:59 PM
> Subject: Re: [zf-contributors] How to package ZF2
>
> -- Kevin McArthur<[hidden email]>  wrote
> (on Wednesday, 01 June 2011, 08:22 AM -0700):
>> On 11-06-01 07:28 AM, Matthew Weier O'Phinney wrote:
>>> -- Kevin McArthur<[hidden email]>   wrote
>>> (on Tuesday, 31 May 2011, 03:43 PM -0700):
>>>> This claim is not accurate. I have been doing this since ZFW came
>>>> out using the well known and well described methods (methods that
>>>> are published and widely used). I have _never_ once run into a class
>>>> resolution issue or picked up a wrong version. It is simply not
>>>> possible to occur with a proper bootstrap which is both simple and
>>>> easily defined.
>>> The claim is inaccurate for *you*. *You* have not had problems. That
>>> does not count as empirical evidence.
>> I also published it in my book, which is widely read and deployed. I
>> receive questions on a regular basis from readers. No one has ever
>> emailed me a question on this topic.
> I'm not questioning that. I'm saying that just because *you* haven't had
> support issues, that doesn't mean *others* have not, either.
>
>>> I comb through the mailing lists, twitter, various forums, and more
>>> regularly -- to see where the problem areas are. Many things that
>>> come easy to me due to my experience are simply hard for other
>>> developers; we all come from different backgrounds and experience.
>> This is why I take a cut-n-paste rather than a
>> figure-it-out-yourself approach to this.
> I really don't know what you're implying by this.
>
> My experience with cut-and-paste solutions is:
>
> * Developers that follow them often don't take the time to understand
>     what is being done, and why it works.
> * Which means that when something breaks, they become quite vocal about
>     the solution not working.
> * If the solution relies on cut-and-paste to mask complexity, this
>     makes education harder.
>
> I'm not advocating a "figure-it-out-yourself" or "RTFM" approach. I'm
> saying that the core of the framework should be easily approachable,
> learnable, and comprehensible (versus comprehensive).
>
> Clearly, our experience differs widely with what works and what doesn't
> in that regard. I'm thinking we need to do some polls around this topic,
> to be honest.
>
>>> I have had to answer quite a number of support questions regarding the
>>> practice of parallel versioned installs and system-level installs. In
>>> fact, one large reason the quick start recommends having the ZF library
>>> linked into the project is due to the number of questions myself, others
>>> on my team, and community contributors have had to answer on the
>>> subject. (The other is due to the complexity of explaining the
>>> include_path, which, while an easy topic for experienced developers, is
>>> really, really hard for newcomers to PHP and/or ZF to learn).
>> If developers use pear, and try to install multiple versions all
>> about the system, yes, they will have problems. They will probably
>> have lots of problems with 'pyrus'es versioned installs. Thats
>> complicated custom syntax.
> I'm not talking about PEAR or Pyrus here. I'm talking about having
> shared ZF installs, either a single install on the include_path or
> versioned installs such as you advocated in your email.
>
>> The method I'm suggesting was pioneered back in the original ZF1
>> development cycle days and _used_ to be the standard. There weren't
>> issues with it then either. If you can extract a file, you can use
>> versioned installs reliably.
>>> So, while a "proper bootstrap" may be simple and easy to define for
>>> some, it's not for others, and often poses new questions: where exactly
>>> was ZF installed? Are there parallel versions? Who linked "latest", and
>>> what does it link to? What happens if the directory is misnamed? Which
>>> autoloader is used? What happens if I have multiple ZF versions on my
>>> include_path?
>> This is why its boiled down to two constants.
> Why have *any* constants? That's a serious question, actually. What if
> we could get away with not using *any*?
>
> As an example, I'm planning on including a .classmap.php file with ZF2.
> What if we also had an _autoload.php file that consumed it as part of a
> simple autoloader? Suddenly, it becomes as easy as:
>
>      include "path/to/zf-install/perhaps-even-version/_autoload.php";
>
>      // start doing stuff
>
>
>> An installed path and a version. Interestingly, if the path cannot be
>> found, the site puts up a really obvious cannot find zend_loader
>> error.
> This is a good point. The problem is that if you have display_errors
> off, or you're not logging errors, or you're relatively new to PHP, it's
> really hard to debug. (Trust me on this one -- autoload functionality in
> ZF1 has been a pain due to trying to cater to a wide range of
> abilities.)
>
>> If you wanted to be extra certain, we could add a check to the
>> bootstrap to ensure the defined version is the loaded version, but
>> I've never seen the need for such a check. That would look like
>>
>> if(!version_compare(ZFW_VERSION, Zend_Version::VERSION, '==')) {
>> throw new RuntimeException('Defined version is not loaded version');
>> } which could be expanded to check latest too if needed... but that
>> would require some sort of entropy entry point to be fast and
>> efficient.
> That's actually a really nice idea, and a good argument for the
> constant. I'd like to see it encapsulated -- we could likely encapsulate
> it in Zend_Version itself:
>
>      Zend_Version::validateVersion(ZFW_VERSION, Zend_Version::ALLOW_SAME_MINOR);
>
> (It wouldn't technically need a constant, actually...)
>
>>> When I deploy to my shared host (or server with multiple sites), how do
>>> I ensure the appropriate version of ZF is available? What happens if one
>>> site upgrades to the latest on the same minor release series -- and my
>>> site using the same series somehow now breaks?
>>>
>> HUH? If the shared host installs a new minor release, your site wont
>> pick it up until you specify it directly. Nothing gets automatically
>> picked up -- which while it could leave your site using an older
>> ZFW, it is by design for QA reasons.
> I was thinking along the lines of specifying just a minor version, not a
> specific version; e.g., using "1.11" instead of "1.11.3". That's where
> that question arises.
>
>> I think you're way overblowing the case against version-ed installs
>> to make it work with already-planned distribution methods.
> Bad assumption, actually. As I've noted, there are reasons the quick
> start doesn't use versioned installs, and it's due to support/education
> issues. In talking to the folks behind Pyrus, they've run into the same
> issues, which is why they're not planning on offering it (and they, too
> have had many requests for it, and not just from ZF folks).
>
>> This is neither complicated nor unreliable. Its tested, widely
>> deployed and simple to understand. Developers who don't know what a
>> include path are simple copy over the index.php set two constants,
>> (the right version and the right framework path) and customize their
>> application.ini. If they can't handle that, they have no business
>> developing a ZFW application and should be using Wordpress.
> I agree that it's simple in concept. And I think we can continue to
> support it in the autoloader and potentially within our documentation;
> since you'll always be able to simply download a tarball/zip and inflate
> it, you will always be able to do this style.
>
> I'm just not 100% sure we should have it as a requirement for
> per-component or full-framework distribution via a CLI/web-based
> installer, particularly if dropping that requirement means we don't need
> to write our own installer.
>

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[David Muir]

It used to take me 5 minutes to upload via Filezilla.
I've now gotten it down to about 30 seconds as well. I zip my deployment into a tarball and upload that via ftp, then trigger a deploy script to unzip server-side and do a folder swap.

I'm not too sure if version handling is *that* important for ZF though. As mentioned, we can easily use Pyrus to grab the latest ZF version to put it wherever you want. I could put it in /library or put it in /some/shared/location/ZendFramework/1.11.7/

For me though, I'm severly limited by what my client's hosting companies offer (no shell, not even sftp!). If I had a bit more control, I'd just do something like this on the server and keep all dependencies under a VCS:
 (I use Bazaar, but the same workflow would work with just about everything else)

$ cd /path/to/project
$ bzr export . /path/to/production/branch
$ phing deploy

The only reason why I use a setup similar to Kevin's is because it reduces the time spent deploying code by nearly 15 minutes when doing the full cycle of testing, staging and production. With shell access, it's really not that big of a deal.

Wil, the apps I maintain are typically in the 2-3MB range (uncompressed), so I'm a small-fry in comparison, but my experience is similar: a couple of apps at most for each client, and only a few clients. I'm just one guy. I can't handle 100 apps ;-) Even if I had 100 client apps running, I wouldn't want them all on the same server anyway.

David

[David Muir]

David Muir wrote

I'm not too sure if version handling is *that* important for ZF though. As mentioned, we can easily use Pyrus to grab the latest ZF version to put it wherever you want. I could put it in /library or put it in /some/shared/location/ZendFramework/1.11.7/

Hmm, I take that back. For the life of me, I can't figure out how to do this with pyrus. How can I install to a custom folder? It seems that no matter what I do, pyrus wants to install stuff to a folder called php:
eg
pyrus mypear /path/to/project/library
pyrus install pear/Net_Socket
# installs to library/php/Net/Socket.php
Also tried:
pyrus set php_dir /path/to/project/library
but that throws an error.

David

[Mike Willbanks]

Kevin,

On pear... I totally agree, cannot be used on a live server.
> Upgrade-in-place is a deal-breaker for anyone serious about proper QA
> testing. I currently use
>

I don't mean to be harsh but why do you feel this way?  I CAN be used on a
live server and can be very very efficient.  Running over 18 web servers at
times we mirror packages to our own custom PEAR repository.  We have
multiple versions that we go in between and then specify the version that we
are upgrading to...

Ex: pear upgrade cb/ZF-1.11.x which is inside of our own PEAR channel that
we simply mirror packages that we utilize.  This allows us to test and
deploy selectively.  On top of this we can state if a package is "stable",
"beta" or "alpha" by the mirroring process allowing for upgrades to be
easier and more selective by environment.

If you are running a single server - that may be why but then there is also
manually handling the packages inside of your own shared folder rather than
that being applied directly to the global packages....

Aka:

/usr/share/php/ZendFramework/VERSION/library/Zend which you could then
customize in a more specialized sense.  More or less having ZF installed
through PEAR/Pyrus is actually a huge win.


>
> /usr/share/php/ZendFramework/ZendFramework-1.11.6/ as an installation
> path... (also have pretty much every other version installed)... then apps
> pick which version to consume through an update to their bootstrap file as
> they run through QA on our beta test server.
>
>
The cons of this approach are HUGE.  I am not talking just small BUT HUGE.
 Running 8 applications that we maintain consistency with a single version
of ZF saves us an extraordinary amount of performance issues - especially
once you start talking about the realpath_cache.  For instance - we've had
to work on tuning this number to avoid memory swapping finding that 32MB was
a huge performance increase but more caused against it.  We come close even
now to overflowing certain buffers at points and if each piece of software
could potentially be calling a specific version of ZF it would be far more
maintenance.  Currently, we upgrade one of our individual development boxes
check our unit tests and do a simple test against the code, then it runs in
a CI environment like our production machines and then followed by a
regression suite on the front end.  Having these in place help.  I realize
that this would then require changing a single file but then across 8
applications we manually need to do this and if it is forgotten will cause
large negative side effects to our production machine.


> Benefit of this approach is that:
>
> 1) you can immediately install the latest version without even considering
> compatibility/upgrade issues
>

I do see this being helpful for a web development firm but I still don't see
it helpful long term.  If I need to fix an issue with my install today
through PEAR i do the following:
pear uninstall cb/ZF;pear install cb/ZF-VERSION and I am back to where I
was.  So testing this is exactly the same except if you are checking a
single site on a production machine.

You could also separate out the share directory based on a VHOST and setup
multiple PEAR installs.  This also works and then you could also achieve
multiple versions by project.  Yes; more maintenance but it would be
approximately the same scale as what you are talking about now.


> 2) developers can immediately use the library in their applications
>

This is a very large pro; however, I believe environments should be running
the same version no matter what.  The reasoning behind this is simple.  It
will save maintenance in the long term.


> 3) never have a QA problem
>

N/A there are always QA problems in software I don't exactly think that this
is relevant.  It could easily be merged with #1.

>
> Cons:
>
> 1) Upgrading for a security release is a pain in the ass... you install the
> new version and then have to run every site through the QA cycle. (However,
> thanks to the new-ish backporting policy for security issues, if your apps
> are reasonably up-to-date you can install a security release in-place on the
> beta server, see if it gets taken well, and apply-in-place on the live
> server. However, this is an exceptional scenario and only used for
> backported security releases... if theres something wrong the
> backport/security release, things could go wrong)
> 2) Not a lot of good versioning control today means its your (developers)
> responsibility to make sure you upgrade sites to latest version in a timely
> fashion. Ops can't do it for you. (Benefit, ops cant do it for you)
>

[Mike Willbanks]

Forgot to send this one to the list :-/

On Tue, Jun 7, 2011 at 9:46 PM, Mike Willbanks <[hidden email]> wrote:

> Thomas,
>
>
>> > On pear... I totally agree, cannot be used on a live server.
>> > Upgrade-in-place is a deal-breaker for anyone serious about proper QA
>> > testing. I currently use
>> >
>> > /usr/share/php/ZendFramework/ZendFramework-1.11.6/ as an installation
>> > path... (also have pretty much every other version installed)... then
>> > apps pick which version to consume through an update to their bootstrap
>> > file as they run through QA on our beta test server.
>>
>> How would you deal with custom patches, for example you found a bug in ZF,
>> which affect one of your projects? Patching the shared library would require
>> QA for every project, wouldn't it? Would you create another copy of the ZF,
>> e.g. "/usr/share/php/ZendFramework/ZendFramework-1.11.7-pre"..? This would
>> be a problem, because this step requires the help of the system
>> administrator. The "project administration" can access the source and
>> installation, but not "/usr/share/...".
>>
>> I am asking, because I am not sure if it is really common to use
>> centralized installations. In the projects I am working on, the ZF is part
>> of the whole application source: We start using "svn external", because not
>> every application need a copy. But when we have to make changes to the ZF
>> source, we can easily add everything to VCS...
>>
>>
> We use PEAR and have it installed through a mirrored version of the ZF
> campus, custom patches are handled today by utilizing the include path -
> aka:
> yourapp/library, /usr/share/php which then allows us to override any Zend
> classes by adding a directory to the library and then keeping the original
> version in the shared location.  This makes adding / removing custom patches
> quick and efficient - we also don't lose the context or areas where the
> custom changes were made.  This is by and large one of the best things we
> have done to ease upgrades and also be able to fix BC breaks before we are
> able to migrate existing code to fix the issue (aka happened on Zend_Form
> about 5 times with certain renderers).  Then we simple copy the old files we
> needed to our custom directory and note where we need to make fixes.
>
> Regards,
>
> Mike
>

[Kevin McArthur-2]

Hey Mike,

I'll try to explain a little better inline.

On 11-06-07 07:42 PM, Mike Willbanks wrote:

> Kevin,
>
>     On pear... I totally agree, cannot be used on a live server.
>     Upgrade-in-place is a deal-breaker for anyone serious about proper
>     QA testing. I currently use
>
>
> I don't mean to be harsh but why do you feel this way?  I CAN be used
> on a live server and can be very very efficient.  Running over 18 web
> servers at times we mirror packages to our own custom PEAR repository.
>  We have multiple versions that we go in between and then specify the
> version that we are upgrading to...

First, we're talking apples and oranges to a large extent. When
discussing pear/pyrus we're talking about something like 'pear install
zend/framework' as it currently exists (ie on zfcampus etc). A single,
non-filesystem-versioned installation dir that is upgraded in-place by
overwriting the existing files. (eg pear upgrade)

>
> Ex: pear upgrade cb/ZF-1.11.x which is inside of our own PEAR channel
> that we simply mirror packages that we utilize.  This allows us to
> test and deploy selectively.  On top of this we can state if a package
> is "stable", "beta" or "alpha" by the mirroring process allowing for
> upgrades to be easier and more selective by environment.

The problem with this is that you will be simultaneously upgrading N
applications. Impossible to QA check in our environment (we do final QA
testing on live as well after an application has been upgraded to make
sure the upgrade took well). That means that time is upgrade + N * (QA
Time Per Site)... which in our case would be serveral days.

>
> If you are running a single server - that may be why but then there is
> also manually handling the packages inside of your own shared folder
> rather than that being applied directly to the global packages....

I am not. Entire cluster of em as it happens.

>
> Aka:
>
> /usr/share/php/ZendFramework/VERSION/library/Zend which you could then
> customize in a more specialized sense.  More or less having ZF
> installed through PEAR/Pyrus is actually a huge win.

Pear as discussed will not install to a versioned directory. This is
part of the problem. The envisioned system as I understand the proposal
is to have whatever version you are installing/upgrading go to something
like /usr/share/php/ZendFramework/library/Zend. Upgrades are performed
in-situ and files overwritten.

>
>     /usr/share/php/ZendFramework/ZendFramework-1.11.6/ as an
>     installation path... (also have pretty much every other version
>     installed)... then apps pick which version to consume through an
>     update to their bootstrap file as they run through QA on our beta
>     test server.
>
>
> The cons of this approach are HUGE.  I am not talking just small BUT
> HUGE.  Running 8 applications that we maintain consistency with a
> single version of ZF saves us an extraordinary amount of performance
> issues - especially once you start talking about the realpath_cache.
>  For instance - we've had to work on tuning this number to avoid
> memory swapping finding that 32MB was a huge performance increase but
> more caused against it.  We come close even now to overflowing certain
> buffers at points and if each piece of software could potentially be
> calling a specific version of ZF it would be far more maintenance.
>  Currently, we upgrade one of our individual development boxes check
> our unit tests and do a simple test against the code, then it runs in
> a CI environment like our production machines and then followed by a
> regression suite on the front end.  Having these in place help.  I
> realize that this would then require changing a single file but then
> across 8 applications we manually need to do this and if it is
> forgotten will cause large negative side effects to our production
> machine.

This is fine for a handful of applications that can go through a unified
QA process, but given that our applications need to go through
per-client testing there's no way we could ever get all of our sites
ready for an upgrade all at once. Its totally infeasible, and we go
through the upgrades ensuring each site gets flipped to the new version
individually. This is actually a simple shell script command to set the
bootstrap value to the new version number, and is as easy as 'site set
constantname value'  (a sed/awk process followed by a commit -m
"upgrading to version $version") ... and then its automatically kicked
to QA... once that sites tested we move on to the next. Not every site
will behave/malfunction in the same way.

Testing in development is no assurance that it'll work in production, so
in our shop, each stage gets fully tested through three stages.
Development, Beta and Release.

At any given time we probably have 3 Zend Framework versions in effect
as sites are upgraded through the new versions.... only a security
update can skip the QA process... which I laid out a bit in my prior
email (it is admittedly a scary event when a security release happens
and we're operating on the fly)

>     Benefit of this approach is that:
>
>     1) you can immediately install the latest version without even
>     considering compatibility/upgrade issues
>
>
> I do see this being helpful for a web development firm but I still
> don't see it helpful long term.  If I need to fix an issue with my
> install today through PEAR i do the following:
> pear uninstall cb/ZF;pear install cb/ZF-VERSION and I am back to where
> I was.  So testing this is exactly the same except if you are checking
> a single site on a production machine.

Not to put too fine a point on this, but this is not transactional. You
will have a period (potentially minutes) where you are without a ZF
library (longer if that install requires a download). If we did this
we'd lose thousands of active sessions and have lots of angry customers
and clients.

Our switch-over _is_ transactional, as the transitional moment is only
as long as it takes to fwrite out the bootstrap file for that site.
(actually a svn update process, but the kick is immediate upon write)

>
> You could also separate out the share directory based on a VHOST and
> setup multiple PEAR installs.  This also works and then you could also
> achieve multiple versions by project.  Yes; more maintenance but it
> would be approximately the same scale as what you are talking about now.

Now we're stretching plausibility. You're already talking versioned
usage of pear (very nonstandard) and now multiple pear installs.
Essentially no-one will use it this way. What I'm advocating for is
simple drag+drop / wget&tar file management -- not trying to teach
custom pear/pyrus commands and setup multiple installations of pear and
link them to vhosts...

>     2) developers can immediately use the library in their applications
>
>
> This is a very large pro; however, I believe environments should be
> running the same version no matter what.  The reasoning behind this is
> simple.  It will save maintenance in the long term.

Environments should have access to the same versions. Applications
should use the same versions as they move through QA, but there are now
multiple applications per machine (sometimes hundreds) and its
impractical to have them all depend on a single, upgraded-in-place,
version of ZF for QA reasons. Its just simply impossible to test that
many sites all at once.

>     3) never have a QA problem
>
>
> N/A there are always QA problems in software I don't exactly think
> that this is relevant.  It could easily be merged with #1.

The QA process is key to the motivations for a versioned install. You
seem to be able to get all your apps ready to take a ZF update at the
same time, and QA test them immediately after an upgrade. We couldn't
ever hope to be able to do this quick enough.

>
>
>     Cons:
>
>     1) Upgrading for a security release is a pain in the ass... you
>     install the new version and then have to run every site through
>     the QA cycle. (However, thanks to the new-ish backporting policy
>     for security issues, if your apps are reasonably up-to-date you
>     can install a security release in-place on the beta server, see if
>     it gets taken well, and apply-in-place on the live server.
>     However, this is an exceptional scenario and only used for
>     backported security releases... if theres something wrong the
>     backport/security release, things could go wrong)
>     2) Not a lot of good versioning control today means its your
>     (developers) responsibility to make sure you upgrade sites to
>     latest version in a timely fashion. Ops can't do it for you.
>     (Benefit, ops cant do it for you)
>

[akrabat]

Even later to the fray - sorry. Catch up from tek11/dpc11 has been a nightmare.

On 31 May 2011, at 22:23, Matthew Weier O'Phinney wrote:

> Late to the fray -- tek11 had abysmal wireless, and as such I'm just now
> catching up...
>
> -- Kevin McArthur <[hidden email]> wrote
> (on Friday, 27 May 2011, 09:13 AM -0700):
>>
>> We should follow a versioned, shared-library approach for the
>> framework itself allowing many versions of the framework to be
>> installed onto a single box and many applications running different
>> versions to be able to pick them up.
>
> Since you raised this point a couple weeks ago, I've talked to well over
> a dozen folks asking about this. Frankly, I'm not in agreement, for a
> variety of reasons.
>
> The majority of developers to whom I've spoken who might need
> functionality like this (primarily developers who work in client firms
> and host client projects) find that it's far simpler to simply include
> the ZF version they're using in their application. This makes it much
> simpler to deploy, because they no longer need to determine if that ZF
> version exists on the server, nor configure where it exists. It makes
> testing the application on new versions simpler as well -- they update
> the version, test, and, if good, re-deploy. Yes, they may end up with
> multiple installs of the same version of the framework on a machine, but
> in practice, this doesn't happen terribly often, and the re-use of
> framework versions happens very little.

I just wanted to add that we work the same was as Kevin does, with multiple versions of ZF in /usr/local/include and each website choosing which version of ZF to install to. We tried to do the one copy of ZF per website, but moved after we hit 20 sites or so using ZF. The main advantage to us is to avoid the very slow checkouts required if you put all of ZF into every single website's version control system. Also,the space starts adding up on my laptop :) Maybe noone else actively maintains as many ZF projects as we do? (or everyone else has much much faster Internet!)

I appreciate that we're a minority, but I'd hate it if ZF2's new deployment system prevented us from being able to have multiple versions server-wide.

Regards,

Rob...


--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[merrix]

My personal take is that with cheap resources, like in the cloud for
instance, your going to get more people deploying apps on at least a
per box basis. I think the 'massive company box' approach is going
away (albeit slowly). In otherwords I think most people will be svn
externalizing or using git submodules on a per app basis.

I do feel the file weight pain, especially when using multiple
libraries (like PHPExcel for example). I have 3 apps checked out on my
personal comp taking about 2.5GB up ^^

Is it possible to satisfy both approaches?

Sent from my iPhone

On Jun 12, 2011, at 11:20 AM, Rob Allen <[hidden email]> wrote:

> Even later to the fray - sorry. Catch up from tek11/dpc11 has been a nightmare.
>
> On 31 May 2011, at 22:23, Matthew Weier O'Phinney wrote:
>
>> Late to the fray -- tek11 had abysmal wireless, and as such I'm just now
>> catching up...
>>
>> -- Kevin McArthur <[hidden email]> wrote
>> (on Friday, 27 May 2011, 09:13 AM -0700):
>>>
>>> We should follow a versioned, shared-library approach for the
>>> framework itself allowing many versions of the framework to be
>>> installed onto a single box and many applications running different
>>> versions to be able to pick them up.
>>
>> Since you raised this point a couple weeks ago, I've talked to well over
>> a dozen folks asking about this. Frankly, I'm not in agreement, for a
>> variety of reasons.
>>
>> The majority of developers to whom I've spoken who might need
>> functionality like this (primarily developers who work in client firms
>> and host client projects) find that it's far simpler to simply include
>> the ZF version they're using in their application. This makes it much
>> simpler to deploy, because they no longer need to determine if that ZF
>> version exists on the server, nor configure where it exists. It makes
>> testing the application on new versions simpler as well -- they update
>> the version, test, and, if good, re-deploy. Yes, they may end up with
>> multiple installs of the same version of the framework on a machine, but
>> in practice, this doesn't happen terribly often, and the re-use of
>> framework versions happens very little.
>
>
> I just wanted to add that we work the same was as Kevin does, with multiple versions of ZF in /usr/local/include and each website choosing which version of ZF to install to. We tried to do the one copy of ZF per website, but moved after we hit 20 sites or so using ZF. The main advantage to us is to avoid the very slow checkouts required if you put all of ZF into every single website's version control system. Also,the space starts adding up on my laptop :) Maybe noone else actively maintains as many ZF projects as we do? (or everyone else has much much faster Internet!)
>
> I appreciate that we're a minority, but I'd hate it if ZF2's new deployment system prevented us from being able to have multiple versions server-wide.
>
> Regards,
>
> Rob...
>
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[Tomáš Fejfar]

What is the problem? You create folders /etc/zend/1.7.2/, etc/zend/1.11/,
... and in you config/initAutoloader you add:

define('ZEND_VERSION', '1.11');
set_include_path('etc/zend/' . ZEND_VERSION);

Or am I missing something?

On Sun, Jun 12, 2011 at 8:44 PM, Grayson Koonce <[hidden email]>wrote:

> My personal take is that with cheap resources, like in the cloud for
> instance, your going to get more people deploying apps on at least a
> per box basis. I think the 'massive company box' approach is going
> away (albeit slowly). In otherwords I think most people will be svn
> externalizing or using git submodules on a per app basis.
>
> I do feel the file weight pain, especially when using multiple
> libraries (like PHPExcel for example). I have 3 apps checked out on my
> personal comp taking about 2.5GB up ^^
>
> Is it possible to satisfy both approaches?
>
> Sent from my iPhone
>
> On Jun 12, 2011, at 11:20 AM, Rob Allen <[hidden email]> wrote:
>
> > Even later to the fray - sorry. Catch up from tek11/dpc11 has been a
> nightmare.
> >
> > On 31 May 2011, at 22:23, Matthew Weier O'Phinney wrote:
> >
> >> Late to the fray -- tek11 had abysmal wireless, and as such I'm just now
> >> catching up...
> >>
> >> -- Kevin McArthur <[hidden email]> wrote
> >> (on Friday, 27 May 2011, 09:13 AM -0700):
> >>>
> >>> We should follow a versioned, shared-library approach for the
> >>> framework itself allowing many versions of the framework to be
> >>> installed onto a single box and many applications running different
> >>> versions to be able to pick them up.
> >>
> >> Since you raised this point a couple weeks ago, I've talked to well over
> >> a dozen folks asking about this. Frankly, I'm not in agreement, for a
> >> variety of reasons.
> >>
> >> The majority of developers to whom I've spoken who might need
> >> functionality like this (primarily developers who work in client firms
> >> and host client projects) find that it's far simpler to simply include
> >> the ZF version they're using in their application. This makes it much
> >> simpler to deploy, because they no longer need to determine if that ZF
> >> version exists on the server, nor configure where it exists. It makes
> >> testing the application on new versions simpler as well -- they update
> >> the version, test, and, if good, re-deploy. Yes, they may end up with
> >> multiple installs of the same version of the framework on a machine, but
> >> in practice, this doesn't happen terribly often, and the re-use of
> >> framework versions happens very little.
> >
> >
> > I just wanted to add that we work the same was as Kevin does, with
> multiple versions of ZF in /usr/local/include and each website choosing
> which version of ZF to install to. We tried to do the one copy of ZF per
> website, but moved after we hit 20 sites or so using ZF. The main advantage
> to us is to avoid the very slow checkouts required if you put all of ZF into
> every single website's version control system. Also,the space starts adding
> up on my laptop :) Maybe noone else actively maintains as many ZF projects
> as we do? (or everyone else has much much faster Internet!)
> >
> > I appreciate that we're a minority, but I'd hate it if ZF2's new
> deployment system prevented us from being able to have multiple versions
> server-wide.
> >
> > Regards,
> >
> > Rob...
> >
> >
> > --
> > List: [hidden email]
> > Info: http://framework.zend.com/archives
> > Unsubscribe: [hidden email]
> >
> >
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>
>

[Paul Court]

Can I just add to the mix that we are in with Rob and Kevin's approach. We have multiple versions of ZF in the filesystem, and in the app we add a symlink to application/library/Zend -> Whichever version that app is using. So I too would be keen to retain the ability to keep many versions.

If the goal is to enable Zend_Tool to be able to self manage, then can it be done and retain the versioning? So that we might have under an appropriate filesystem path (like /usr/share/ZendFramework/):-

.../2.1
.../2.2
.../2.3
.../etc
../current -> ./2.3

Then ZT can maintain its own symlink to the latest version. Maybe with a little work you could have a "dev" symlink too to mike life easier for people that would be working on HEAD on their dev machines and wanting it running under an environment as close to the "live" version.

Regards
Paul
(aka Gargoyle)

PS. Apologies if I have replied incorrect - I'm a bit of a mailing list newbie and not sure on the right thing with regards to cc, etc



On 14 Jun 2011, at 12:43, Tomáš Fejfar wrote:

> What is the problem? You create folders /etc/zend/1.7.2/, etc/zend/1.11/,
> ... and in you config/initAutoloader you add:
>
> define('ZEND_VERSION', '1.11');
> set_include_path('etc/zend/' . ZEND_VERSION);
>
> Or am I missing something?
>
> On Sun, Jun 12, 2011 at 8:44 PM, Grayson Koonce <[hidden email]>wrote:
>
>> My personal take is that with cheap resources, like in the cloud for
>> instance, your going to get more people deploying apps on at least a
>> per box basis. I think the 'massive company box' approach is going
>> away (albeit slowly). In otherwords I think most people will be svn
>> externalizing or using git submodules on a per app basis.
>>
>> I do feel the file weight pain, especially when using multiple
>> libraries (like PHPExcel for example). I have 3 apps checked out on my
>> personal comp taking about 2.5GB up ^^
>>
>> Is it possible to satisfy both approaches?
>>
>> Sent from my iPhone
>>
>> On Jun 12, 2011, at 11:20 AM, Rob Allen <[hidden email]> wrote:
>>
>>> Even later to the fray - sorry. Catch up from tek11/dpc11 has been a
>> nightmare.
>>>
>>> On 31 May 2011, at 22:23, Matthew Weier O'Phinney wrote:
>>>
>>>> Late to the fray -- tek11 had abysmal wireless, and as such I'm just now
>>>> catching up...
>>>>
>>>> -- Kevin McArthur <[hidden email]> wrote
>>>> (on Friday, 27 May 2011, 09:13 AM -0700):
>>>>>
>>>>> We should follow a versioned, shared-library approach for the
>>>>> framework itself allowing many versions of the framework to be
>>>>> installed onto a single box and many applications running different
>>>>> versions to be able to pick them up.
>>>>
>>>> Since you raised this point a couple weeks ago, I've talked to well over
>>>> a dozen folks asking about this. Frankly, I'm not in agreement, for a
>>>> variety of reasons.
>>>>
>>>> The majority of developers to whom I've spoken who might need
>>>> functionality like this (primarily developers who work in client firms
>>>> and host client projects) find that it's far simpler to simply include
>>>> the ZF version they're using in their application. This makes it much
>>>> simpler to deploy, because they no longer need to determine if that ZF
>>>> version exists on the server, nor configure where it exists. It makes
>>>> testing the application on new versions simpler as well -- they update
>>>> the version, test, and, if good, re-deploy. Yes, they may end up with
>>>> multiple installs of the same version of the framework on a machine, but
>>>> in practice, this doesn't happen terribly often, and the re-use of
>>>> framework versions happens very little.
>>>
>>>
>>> I just wanted to add that we work the same was as Kevin does, with
>> multiple versions of ZF in /usr/local/include and each website choosing
>> which version of ZF to install to. We tried to do the one copy of ZF per
>> website, but moved after we hit 20 sites or so using ZF. The main advantage
>> to us is to avoid the very slow checkouts required if you put all of ZF into
>> every single website's version control system. Also,the space starts adding
>> up on my laptop :) Maybe noone else actively maintains as many ZF projects
>> as we do? (or everyone else has much much faster Internet!)
>>>
>>> I appreciate that we're a minority, but I'd hate it if ZF2's new
>> deployment system prevented us from being able to have multiple versions
>> server-wide.
>>>
>>> Regards,
>>>
>>> Rob...
>>>
>>>
>>> --
>>> List: [hidden email]
>>> Info: http://framework.zend.com/archives
>>> Unsubscribe: [hidden email]
>>>
>>>
>>
>> --
>> List: [hidden email]
>> Info: http://framework.zend.com/archives
>> Unsubscribe: [hidden email]
>>
>>
>>

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]