Re: [Zope3-dev] Test layers for zope.app.* packages
On 2/5/07, Baiju M <[EMAIL PROTECTED]> wrote: I have created zope.app egg two weeks back (http://svn.zope.org/zope.app/trunk/) I have used setuptools.find_packages function, so setuptools is a dependency. Should we need compatibility with distutils.core ? I suspect it's fine ok for an egg-supporting setup.py to depend on setuptools, though I'm wary of dependencies outside the Python standard library and our own code for basics. Using zc.buildout ensures setuptools is part of a buildout anyway, so I'll get over my own little hangup pretty quickly. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Test layers for zope.app.* packages
Jim Fulton wrote: On Feb 5, 2007, at 4:40 AM, Baiju M wrote: > We have to add test layer for each packages in zope.app namespace. I think we should. I'm not sure we *need* to. I certainly don't want to do this if it will delay full eggification. As I've mentioned before, I'd be perfectly happy to see a large zope.app egg containing everything we had in previous releases as a start. We could always break packages off later. I have created zope.app egg two weeks back (http://svn.zope.org/zope.app/trunk/) I have used setuptools.find_packages function, so setuptools is a dependency. Should we need compatibility with distutils.core ? Regards, Baiju M ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: zodbcode vs zope.app.module and zope.app.interface.PersistentInterface
Ross Patterson <[EMAIL PROTECTED]> writes: > Ross Patterson <[EMAIL PROTECTED]> writes: > >> zope.app.interface.PersistentInterface gets used properly for >> persistent modules containing classes that subclass >> zope.interface.Interface when those modules are are managed and >> registered through managers and registries from zodbcode. However, >> similar persistent modules are broken when managed and registered >> through managers and registries from zope.app.module. Attached is a >> diff against zope.app.module that adds a test demonstrating the >> failure. >> >> I'll create an issue in the collector if I can't fix this, but I hope >> to fix it. >> >> What I'd like to know is why zope.app.module seems to have totally >> independent manager and registry implementaitons from those found in >> zodbcode. It looks like Fred Drake did a lot of the work on zodbcode >> and Setphan Richter did a lot of the work on zope.app.module, so I was >> hoping to learn something about the rationale from one or both of >> you. Is there any reason not to realign the implmentations in >> zope.app.module with those in zodbcode? >> >> I realize that most of this work was done long ago, but I appreciate >> any insight. >> >> Ross > > Attached is a new verion of the patch against zope.app.module that I > think is a bit clearer. It demonstrates that the manager from > zodbcode works where the manager from zope.app.module doesn't. > > Ross I figured this out and demonstrated the workaround in a doc file and test: http://svn.zope.org/Zope3/trunk/src/zope/app/module/?rev=72384&view=rev Ross ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Test layers for zope.app.* packages
Jim Fulton wrote: I *really* want to be able to have the current Zope 3 application assembled entirely from eggs by the end of PyCon. Me too! :) Not that I'm helping (much?), but the Plone people are getting all excited about eggs. We even have a monstrous Plone egg that contains all of Plone's products (still a bit experimental and throws some warnings because it's trying to bytecompile Scripts in skin folders, but oh well). Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: zodbcode vs zope.app.module and zope.app.interface.PersistentInterface
Ross Patterson <[EMAIL PROTECTED]> writes:
> zope.app.interface.PersistentInterface gets used properly for
> persistent modules containing classes that subclass
> zope.interface.Interface when those modules are are managed and
> registered through managers and registries from zodbcode. However,
> similar persistent modules are broken when managed and registered
> through managers and registries from zope.app.module. Attached is a
> diff against zope.app.module that adds a test demonstrating the
> failure.
>
> I'll create an issue in the collector if I can't fix this, but I hope
> to fix it.
>
> What I'd like to know is why zope.app.module seems to have totally
> independent manager and registry implementaitons from those found in
> zodbcode. It looks like Fred Drake did a lot of the work on zodbcode
> and Setphan Richter did a lot of the work on zope.app.module, so I was
> hoping to learn something about the rationale from one or both of
> you. Is there any reason not to realign the implmentations in
> zope.app.module with those in zodbcode?
>
> I realize that most of this work was done long ago, but I appreciate
> any insight.
>
> Ross
Attached is a new verion of the patch against zope.app.module that I
think is a bit clearer. It demonstrates that the manager from
zodbcode works where the manager from zope.app.module doesn't.
Ross
Index: interfaces.txt
===
--- interfaces.txt (revision 0)
+++ interfaces.txt (revision 0)
@@ -0,0 +1,24 @@
+;-*-Doctest-*-
+=
+Persistent Interfaces
+=
+
+Verify that persistent interfaces cooperate::
+
+ >>> from zodbcode.module import PersistentModuleRegistry
+ >>> from zodbcode.module import PersistentModuleManager
+ >>> from zope.app.module.manager import ModuleManager
+ >>> p_registry = PersistentModuleRegistry()
+ >>> p_manager = PersistentModuleManager(p_registry)
+ >>> manager = ModuleManager()
+
+ >>> source = """\n
+ ... from zope.interface import Interface
+ ... class IFoo(Interface): pass
+ ... """
+ >>> p_manager.new('foo', source)
+ >>> p_manager._module
+
+ >>> manager.source = source
+ >>> manager.getModule()
+
Index: tests.py
===
--- tests.py (revision 72377)
+++ tests.py (working copy)
@@ -34,7 +34,8 @@
def test_suite():
return unittest.TestSuite((
-doctest.DocFileSuite('README.txt', setUp=setUp, tearDown=tearDown),
+doctest.DocFileSuite('README.txt', 'interfaces.txt',
+ setUp=setUp, tearDown=tearDown),
))
if __name__ == "__main__":
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Test layers for zope.app.* packages
On Feb 5, 2007, at 4:40 AM, Baiju M wrote: We have to add test layer for each packages in zope.app namespace. I think we should. I'm not sure we *need* to. I certainly don't want to do this if it will delay full eggification. As I've mentioned before, I'd be perfectly happy to see a large zope.app egg containing everything we had in previous releases as a start. We could always break packages off later. I *really* want to be able to have the current Zope 3 application assembled entirely from eggs by the end of PyCon. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.app.twisted.main?
On 5 Feb 2007, at 11:50 , Chris Withers wrote: Philipp von Weitershausen wrote: Perhaps there's not a need for that separation in the Zope 3 core with packages like zope.paste around... Sorry, you lost me... there's what a need for what seperation? What I meant: Since is we have things like zope.paste which work fine as 3rd party packages already, perhaps the Zope 3 core just needs to *support* this separation of server configuration and application definition, but doesn't necessarily need to *do* it. Yes, the publication in Zope 3 (which was written at an very early stage with a lot of Zope 2 background) has a method "getApplication", but all it does is return the root object. So let's reflect that name in the utility. Right, okay, my mistake, that's what I was referring to... It just occurred to me that we could make those IRootObjectFactory things named utilities. Then you cna register as many of them at the same time and just choose which one you want using a switch in, say, zope.conf. Why named? If only so you can register many of them, then I call yagni. Like a unix file system, a zope instance should only have one root :-) Sure. But the use of named utilities would make it a tad easier because you wouldn't need ZCML overrides. Let's say Zope 3 defines an IRootObjectFactory utility called 'zope.app.appsetup'. So, a default zope.conf would look like this: # root-object-factory -- name of an IRootObjectFactory utility that the # publication will use to create the root object. # # Default: root-object-factory zope.app.appsetup Now, let's say you want to plug in a custom root object from, say, SQL. You'd write your own IRootObjectFactory utility, register it like so: and flip the switch in zope.conf: root-object-factory my.great.factory Actual spellings may and probalby should, of course, be subject to change. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.app.twisted.main?
Philipp von Weitershausen wrote: Perhaps there's not a need for that separation in the Zope 3 core with packages like zope.paste around... Sorry, you lost me... there's what a need for what seperation? I thik we can stick with ZConfig for now, even though Jim doesn't like it... *wink* ;) I love ZConfig, so I'm okay :-) Yes, the publication in Zope 3 (which was written at an very early stage with a lot of Zope 2 background) has a method "getApplication", but all it does is return the root object. So let's reflect that name in the utility. Right, okay, my mistake, that's what I was referring to... It just occurred to me that we could make those IRootObjectFactory things named utilities. Then you cna register as many of them at the same time and just choose which one you want using a switch in, say, zope.conf. Why named? If only so you can register many of them, then I call yagni. Like a unix file system, a zope instance should only have one root :-) (anything else can be wired in below that...) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Test layers for zope.app.* packages
Hi, We have to add test layer for each packages in zope.app namespace. I have added few of them. This is easy but massive task, boring too :) Here is the remaining list of packages: apidoc applicationcontrol authentication boston component dav debugskin exception file generations http i18nfile onlinehelp pagetemplate publication publisher rotterdam securitypolicy session sqlscript workflow xmlrpcintrospection zptpage Regards, Baiju M ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zodbcode vs zope.app.module and zope.app.interface.PersistentInterface
zope.app.interface.PersistentInterface gets used properly for
persistent modules containing classes that subclass
zope.interface.Interface when those modules are are managed and
registered through managers and registries from zodbcode. However,
similar persistent modules are broken when managed and registered
through managers and registries from zope.app.module. Attached is a
diff against zope.app.module that adds a test demonstrating the
failure.
I'll create an issue in the collector if I can't fix this, but I hope
to fix it.
What I'd like to know is why zope.app.module seems to have totally
independent manager and registry implementaitons from those found in
zodbcode. It looks like Fred Drake did a lot of the work on zodbcode
and Setphan Richter did a lot of the work on zope.app.module, so I was
hoping to learn something about the rationale from one or both of
you. Is there any reason not to realign the implmentations in
zope.app.module with those in zodbcode?
I realize that most of this work was done long ago, but I appreciate
any insight.
Ross
Index: interfaces.txt
===
--- interfaces.txt (revision 0)
+++ interfaces.txt (revision 0)
@@ -0,0 +1,16 @@
+;-*-Doctest-*-
+=
+Persistent Interfaces
+=
+
+Verify that persistent interfaces cooperate::
+
+ >>> from zope.app.module.manager import ModuleManager
+ >>> manager = ModuleManager()
+
+ >>> manager.source = """\n
+ ... from zope.interface import Interface
+ ... class IFoo(Interface): pass
+ ... """
+ >>> manager.getModule()
+
Index: tests.py
===
--- tests.py (revision 72365)
+++ tests.py (working copy)
@@ -34,7 +34,8 @@
def test_suite():
return unittest.TestSuite((
-doctest.DocFileSuite('README.txt', setUp=setUp, tearDown=tearDown),
+doctest.DocFileSuite('README.txt', 'interfaces.txt',
+ setUp=setUp, tearDown=tearDown),
))
if __name__ == "__main__":
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
