On 10/7/07, Brandon Craig Rhodes <[EMAIL PROTECTED]> wrote:
> There is danger here.  Many in the industry consider Linux to be an
> absolute disaster - because after you develop an application on one
> distribution, you can spend months trying to support customers who
> attempt to run it on other distributions!  In the wider Unix world
> things are even worse.  Tools like "autoconf" absorb months and years
> of developer effort to simply get products to compile everywhere.

Right, but the problem I think is that people say that applications
run on Linux, and also spend time to make them do so, and that needs a
lot of time spent.

I think that an application running on a pure Zope 3 would run also on
Grok, but it would be entirely possible to make another application
that for example doesn't use the ZODB at all, but still uses the rest
of the Zope3 "ecosystem". And an application running on Zope 3.3,
would not run on such a distribution.

So if we make Zope3 less of an application and more of a
platform/environment/ecosystem, we should probably not say that
anything runs "on" Zope3, and that would then solve that problem.
Applications would *run on* Grok, but *use* zope 3.

But I suspect that we then end up with your "Python" model, right? :-)

> Now, it sounds like Zope is about to stop being like Python and start
> being like the current Wild West of Linux distributions.  If I want to
> write a WebWidget in the future, and want it to work with Grok, and
> Zope on Wheels, and ZopeSprockets, and whatever other frameworks might
> come along, then I will be faced with situations like "Well, Grok has
> already moved up to zope.security 3.7, which means I can use key cards
> natively!  Hmm, but the other frameworks have not upgraded past 3.6; I
> will have to special-case key-cards for them.  On the other hand, Grok
> stayed with zope.templates 3.5 because they piled so many extensions
> on top that they didn't get time to redevelop them for 3.6, so I'm
> going to have to fake push-masking in Grok..."

Yeeeessss, I see your point.  But is this avoidable at all? Even with
more fixed sets of versions we have this exact problem already today.

"I would like to use utilities, but Plone 2.5 is still on Zope 2.9
which has a slightly different utility implementation than Plone 3, so
I'm going to have to specialcase for that, and at the same time I'd
like to use this under Grok which has moved on to zope 3.4"... and so
on. I think that with the granular versions we get with eggs, it's in
fact gonna be *easier* to avoid this stuff, because I could in my
application update to a newer version of the module I need, and it
wouldn't actually break anything except in those cases where the
module breaks backwards compatibility, which isn't supposed to happen,
except in some extreme circumstances nowadays.

Lennart Regebro: Zope and Plone consulting.
+33 661 58 14 64
Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to