Baiju M wrote:
On 11/5/06, Jim Fulton <[EMAIL PROTECTED]> wrote:
I meant to note that the efforts to eggify many packages
is a crucial and much appreciated first step in the effort
to get an agg-based Zope 3 (and someday Zope 2) checkout and
Now most of the zope.* packages are eggified, but some packages should be
considered broken because it's functional testing are not working.
We have to use test layers for functional testing with at least one
layer per package based on ZCMLLayer ?
Ideally, yes. This should be our goal.
> Then there will be
TestBroserLayer, PublisherLayer etc.
or should we create a ZopeAppServerLayer derived from ZCMLLayer and
use it for the packages where application server is required to run
See Fred's response. Note that an alternative, in the short term
is to create a buildout that either includes or uses an
existing Zope 3 installation. This will allow the existing
functional alyer to be used. It requires specifying the Zope 3
src directory in the extra-paths option of the testrunner section.
To eggify zope.app.* packages we should implement this proposal ? :
I have implemented this in my checkout with an ugly hack and tried to
one package, can anyone review this ?
I don't have time to look at this atm.
Where do we place zope.app.* individual packages in subversion?
If we are placing it in toplevel (under main) there will be about 90+
What about creating a 'zope.app' directory in toplevel and put all
zope.app.* packages there ?
This is a good question. Several months ago, the same questions was
raised wrt Zope 2 Products, which are mostly in the Products package.
At the time, we decided to stick with top-level projects because:
- That was the subversion standard practice, and
- Shallow is better than deep, in general.
I wonder, however, if that was the best decision.
The list of projects at:
Is already rather long and unweildy, It is likely to get worse.
The fact that most things begin with "z" makes it even harder to
Personally, I wouldn't object to organizing things by namespace
packages. Of course, zope.app is an odd case because there will be
both a zope.app namespace package and a project that we'd be tempted
to name zope.app.
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Zope3-dev mailing list