AW: [Checkins] SVN: z3c.jbot/ Initial import.
Hi Malthe
Betreff: [Checkins] SVN: z3c.jbot/ Initial import.
Log message for revision 81997: Initial import.
[...]
+ >>> from Products.Five.browser.pagetemplatefile import + ZopeTwoPageTemplateFile
I really like what you are doing, cool ideas! But I also have a question. Should we not use another namspace for Zope packages which depend on Five or other packages then zope.* or z3c.*? I'm not sure about that, it's just a question. What do you think about a namespace called z5c or something like that? I guess it's easier to explain the different core concepts if we separate them in base libraries. Or is it possible to skip the Five dependency and implement Five support in a second layer/package? btw, I think since we use buildout, it's not possible to implement mixed Zope3/Five packages bacause setup has to define the Five packages too. right? Regards Roger Ineichen
But I also have a question. Should we not use another namspace for Zope packages which depend on Five or other packages then zope.* or z3c.*?
The package makes no assumptions that Five is available, but there are tests for a scenario where it is. \malthe
Hi Malthe
Betreff: Re: [Checkins] SVN: z3c.jbot/ Initial import.
But I also have a question. Should we not use another namspace for Zope packages which depend on Five or other packages then zope.* or z3c.*?
The package makes no assumptions that Five is available, but there are tests for a scenario where it is.
Thanks, sounds good to me if it's only for testing. Regards Roger Ineichen
Roger Ineichen wrote:
Hi Malthe
Betreff: Re: [Checkins] SVN: z3c.jbot/ Initial import.
But I also have a question. Should we not use another namspace for Zope packages which depend on Five or other packages then zope.* or z3c.*? The package makes no assumptions that Five is available, but there are tests for a scenario where it is.
Thanks, sounds good to me if it's only for testing.
Except that if those tests are only run after manual intervention (i.e., after editing something in the checkout or environment), then if a hapless contributor can check out z3c.jbot, make changes, run the tests (and they all pass), and check in the changes and those changes may have broken the parts of the code that only are tested if Five is around. These sorts of situations are where "works out of the box" testing really helps. Maybe I'm misunderstanding how these tests are set up. -- Benji York Senior Software Engineer Zope Corporation
Roger Ineichen wrote:
Hi Malthe
Betreff: [Checkins] SVN: z3c.jbot/ Initial import.
Log message for revision 81997: Initial import.
[...]
+ >>> from Products.Five.browser.pagetemplatefile import + ZopeTwoPageTemplateFile
I really like what you are doing, cool ideas!
But I also have a question. Should we not use another namspace for Zope packages which depend on Five or other packages then zope.* or z3c.*?
We do have the 'five' namespace for things like that, by the way (so far it's used by five.intid and five.localsitemanager, for instance).
I'm not sure about that, it's just a question. What do you think about a namespace called z5c or something like that? I guess it's easier to explain the different core concepts if we separate them in base libraries.
Or is it possible to skip the Five dependency and implement Five support in a second layer/package?
-1 to magic or weak dependencies. +1 to "test what you fly and fly what you test"
btw, I think since we use buildout, it's not possible to implement mixed Zope3/Five packages bacause setup has to define the Five packages too. right?
In general, it makes the reuse of a package difficult if it depends on Zope 2 stuff (incl. Five).
-1 to magic or weak dependencies. +1 to "test what you fly and fly what you test"
I agree. In this case it would make sense to have five.jbot. If everyone's in favor, I can split it out like that. It's an interesting situation though because the package in question does not have any code that depends on zope 2 in any way. \malthe
On Wed, 28 Nov 2007 11:45:10 -0800, Malthe Borch <mborch@gmail.com> wrote:
-1 to magic or weak dependencies. +1 to "test what you fly and fly what you test"
I agree. In this case it would make sense to have five.jbot. If everyone's in favor, I can split it out like that. It's an interesting situation though because the package in question does not have any code that depends on zope 2 in any way.
While we're on a renaming spree here, why "jbot"? (I know, Just a Bunch of Templates) My associations go to IRC or spam bots immediately. :) -- Alexander Limi ยท http://limi.net
On Wednesday 28 November 2007, Malthe Borch wrote:
-1 to magic or weak dependencies. +1 to "test what you fly and fly what you test"
I agree. In this case it would make sense to have five.jbot. If everyone's in favor, I can split it out like that. It's an interesting situation though because the package in question does not have any code that depends on zope 2 in any way.
+1 Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
Philipp von Weitershausen wrote:
btw, I think since we use buildout, it's not possible to implement mixed Zope3/Five packages bacause setup has to define the Five packages too. right?
In general, it makes the reuse of a package difficult if it depends on Zope 2 stuff (incl. Five).
As Malthe explains, the implementation does not depend on Five, the tests do. Is he supposed to put the Five dependent tests into a different package? I think there's little to gain from that, and the added burden of having two packages. And, I don't see why patching a base class that both Zope 3 and Zope 2 share is a "magic dependency". Daniel
participants (7)
-
Alexander Limi -
Benji York -
Daniel Nouri -
Malthe Borch -
Philipp von Weitershausen -
Roger Ineichen -
Stephan Richter