Re: [Zope-dev] [Fwd: [Bug 376907] Re: AttributeError: 'str' object has no attribute 'registerSynch']
Am 15.05.2009 um 15:24 schrieb Tim Cook: [...] > Traceback here: > = > 2009-05-15 08:30:05,890 ERROR [SiteError] http://localhost:8080 > Traceback (most recent call last): > File > "/home/tim/.buildout/eggs/zope.publisher-3.4.6-py2.5.egg/zope/ > publisher/publish.py", line 129, in publish >obj = publication.getApplication(request) > File > "/home/tim/.buildout/eggs/grok-1.0a3-py2.5.egg/grok/publication.py", > line 70, in getApplication >result = super(ZopePublicationSansProxy, > self).getApplication(request) > File > "/home/tim/.buildout/eggs/zope.app.publication-3.4.3-py2.5.egg/zope/ > app/publication/zopepublication.py", line 150, in getApplication >conn = self.db.open(version) You use a really ancient version of zope.app.publication. This bug was fixed in version 3.5.0 of zope.app.publication. I think at least this version is required to be used together with ZODB 3.9. Yours sincerely, -- Michael Howitz · m...@gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Mailinglist for Zope 2 bugs!?
Thanks for this! 2009/5/14 Andreas Jung : > > All Zope 2 tracker notifications go now all to a new > mailinglist: > > http://mail.zope.org/mailman/listinfo/zope2-tracker > > Notification mails will no longer be send to the individual > members of the Zope 2 team @ Launchpad. > > People interested in bugtracker notifications must subscribe > to the list above > > Thanks to Sidnei and Jens for helping. > > Andreas > > On 13.05.09 16:51, Andreas Jung wrote: >> On 12.05.09 16:49, Sidnei da Silva wrote: >> >> That's not needed. Since the zope2-dev team is automatically subscribed to issues, we only need to set it's contact address. If we set that address to zope-...@lists.zope.org, then issues will automatically be delivered to it. >>> >>> >> Based on yesterdays discussion, I propose to setup a new mailman >> list 'zope2-trac...@zope.org' (or propose a better name) that will be >> added as primary contact address of the Zope 2 team @ Launchpad. >> >> So anyone can subscribe to Zope 2 ticket changes without having >> to be a member of the Zope 2 team. >> >> >> Objections? >> >> Andreas >> >> >> >> >> >> ___ >> Zope-Dev maillist - zope-...@zope.org >> http://mail.zope.org/mailman/listinfo/zope-dev >> ** No cross posts or HTML encoding! ** >> (Related lists - >> http://mail.zope.org/mailman/listinfo/zope-announce >> http://mail.zope.org/mailman/listinfo/zope ) >> > > > -- > ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany > Web: www.zopyx.com - Email: i...@zopyx.com - Phone +49 - 7071 - 793376 > Registergericht: Amtsgericht Stuttgart, Handelsregister A 381535 > Geschäftsführer/Gesellschafter: ZOPYX Limited, Birmingham, UK > > E-Publishing, Python, Zope & Plone development, Consulting > > > > ___ > Zope-Dev maillist - zope-...@zope.org > http://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://mail.zope.org/mailman/listinfo/zope-announce > http://mail.zope.org/mailman/listinfo/zope ) > > -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.container analysis
Previously Martijn Faassen wrote: > If we wanted to make zope.container agnostic about traversal and the > publisher, we'd need to move this code somewhere else. I cannot think of > an existing package for this (anyone?). Lacking that, I'd suggest a new > package, zope.containertraversing or something like that. It could be an extra ;) Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Fwd: [Bug 376907] Re: AttributeError: 'str' object has no attribute 'registerSynch']
I forgot to explicitly ask the question. Where do I file this bug report? Thanks, Tim On Fri, 2009-05-15 at 10:24 -0300, Tim Cook wrote: > This is a bug I filed against ZODB3.9.0b1 > As you can see Jim says it is a bug in zope.app.publication but there is > no Launchpad project to forward the bug to for this module. > > The full text of the bug report is below the double lines. > > Thanks, > Tim > > > Forwarded Message > From: Jim Fulton > Reply-to: Bug 376907 <376...@bugs.launchpad.net> > To: timothywayne.c...@gmail.com > Subject: [Bug 376907] Re: AttributeError: 'str' object has no attribute > 'registerSynch' > Date: Fri, 15 May 2009 12:53:47 - > > This is a bug in zope.app.publication. It shouldn't pass a version to > open. > > > ** Changed in: zodb >Status: New => Won't Fix > > == > > ZODB3.9.0b1 - > Linux x86_64 AMD - Grok 10a3. > > Server starts. Creates a new Data.fs, etc. When attempting to open > http://localhost:8080/applications to add my Grok apps I get this error. > > Traceback here: > = > 2009-05-15 08:30:05,890 ERROR [SiteError] http://localhost:8080 > Traceback (most recent call last): > File > "/home/tim/.buildout/eggs/zope.publisher-3.4.6-py2.5.egg/zope/publisher/publish.py", > line 129, in publish > obj = publication.getApplication(request) > File > "/home/tim/.buildout/eggs/grok-1.0a3-py2.5.egg/grok/publication.py", > line 70, in getApplication > result = super(ZopePublicationSansProxy, > self).getApplication(request) > File > "/home/tim/.buildout/eggs/zope.app.publication-3.4.3-py2.5.egg/zope/app/publication/zopepublication.py", > line 150, in getApplication > conn = self.db.open(version) > File > "/home/tim/.buildout/eggs/ZODB3-3.9.0b1-py2.5-linux-x86_64.egg/ZODB/DB.py", > line 759, in open > result.open(transaction_manager) > File > "/home/tim/.buildout/eggs/ZODB3-3.9.0b1-py2.5-linux-x86_64.egg/ZODB/Connection.py", > line 1052, in open > transaction_manager.registerSynch(self) > AttributeError: 'str' object has no attribute 'registerSynch' > === > > -- Timothy Cook, MSc Health Informatics Research & Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook ** *You may get my Public GPG key from popular keyservers or * *from this link http://timothywayne.cook.googlepages.com/home* ** signature.asc Description: This is a digitally signed message part ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Why does restrictedTraverse() in Zope 2 not respect IPublishTraverse adapters?
On Thu, May 14, 2009 at 10:55:40PM +0200, Laurence Rowe wrote:
> > For maximum portability across Z2 / Z3 / BFG, you could just do the same
> > thing and implement __getitem__ on any object you want to be traversable
> > by either the publisher or APIs like (un)restrictedTraverse, and forego
> > the over-complicated component-laden traversal dance. ;)
>
> Minimal example demonstrating this with a view in zope2:
>
> >>> from zope.component import getSiteManager
> >>> from Testing.makerequest import makerequest
> >>> from zope.publisher.browser import IBrowserView
> >>> from Acquisition import Explicit
> >>> from zope.component import getSiteManager
> >>> app = makerequest(app)
> >>> smgr = getSiteManager()
> >>> class Foo(Explicit):
> ... def __init__(self, context, request):
> ... self.context, self.request = context, request
> ... def __getitem__(self, key):
> ... return int(key)
> ...
> >>> smgr.registerAdapter(Foo, (None, IRequest), IBrowserView, name='foo')
> >>> app.unrestrictedTraverse('@@foo/12345')
> 12345
Thanks for reminding me of this. I keep forgetting that this works!
I only add that if you want to use __getitem__ for publishing, the
items you return should inherit from Acquisition.(Im|Ex)plicit to make
the security machinery happy.
--
Paul Winkler
http://www.slinkp.com
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.intid/trunk/ - Remove a dependency on ``zope.container.contained.Contained``
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: > We might consider moving IContained to zope.location - it just > subclasses from ILocation after all and doesn't add anything besides > being a marker interface. zope.intid already depends on zope.location. > The Contained implementation could even move to zope.location, actually. > > Hm, I wonder what code actually *depends* on IContained (instead > implements it). +1 to moving IContained into zope.location. +lots to removing it altogether, if possible: I'm afraid that there are going to be a few intractable component registrations against it "in the wild", however. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKDZ/Y+gerLs4ltQ4RAnnEAKCaXlLL1wsA1RUJeUTWwj98DNzeqQCdH2Av uSwUKR0xsNw7H411LagHneY= =WbeS -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.intid/trunk/ - Remove a dependency on ``zope.container.contained.Contained``
On 5/15/09 6:27 AM, Fred Drake wrote: > On Fri, May 15, 2009 at 2:57 AM, Chris McDonough wrote: >> It's a partial step towards getting rid of a dependency that zope.intid has >> on >> zope.container. I'm thinking that maybe that IContained interface belongs in >> some other package (e.g. maybe zope.contained). That Container base class >> is.. >> uh.. not complicated, so even if we never do get rid of the zope.container >> dependency completely, it really doesn't harm anything to not use Contained. >> Unless you have some nostalgia for it. ;-) > > At the rate we're going, every class and every interface is going to > be in a separate package. > > Keeping the dependency graph clean is great, and there's plenty to do > there. But there's also something to be said about being able to keep > a substantial portion of it in your head. The cleanliness of the > graph isn't so important if most users still can't understand just > because there are so many pieces that they wouldn't normally use > directly. This particular changes is a nobrainer. It replaces a base class that defines __parent__ and __name__ as None. It just can't be more understandable to have IntIds subclass from Contained for a new developer. When it subclasses from Contained, they have go look over there to see if it does anything interesting and it just doesn't. Breaking small import dependencies like this one is useful even if you don't manage to break any full package dependencies, if only to get the "little stuff" out of the way to start thinking about whether it makes sense to do anything larger. I *didn't* make any other changes because I don't know what the right thing is wrt interfaces and such, and I don't want to make things even worse. - C ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.container analysis
Stephan Richter wrote: > On Friday 15 May 2009, Martijn Faassen wrote: >> It's tempting to start pushing more interfaces (and exceptions) down >> into zope.browser to break dependencies further. It does run the risk of >> turning zope.browser into a bit of a mash though. Perhaps that's worth >> it. Opinions, anyone? > > zope.browser should not become an iface garbage collector. I think that > interfaces not related to browser code deserve a new interfaces package. Sure, that's why I said it's tempting, not that we should do it. When refactoring for dependency cleanup, we should do mechanical analysis about what we could move. We should also always consider whether moving it makes enough sense. And we should consider the goals of moving anything. Chris did the mostly mechanical analysis but didn't speak much about goals. Now I'll do a bit of "does moving stuff make sense" analysis: I think these relate to browser code: * browser.IBrowserRequest, * browser.IBrowserPublisher * NotFound * IDefaultViewName, * IPublishTraverse This one doesn't: * xmlrpc.IXMLRPCPublisher These don't seem to either: * ITraversable * IContainmentRoot I'm don't think there's a clear case to move any of these, however - these interfaces belong in their packages, and moving these interfaces down into zope.browser would move assumptions into zope.browser about the way the publisher works, and we'd still depend on this stuff with zope.container. Let's think about goals. A possible goal is that we'd like to make zope.container independent from zope.publisher and zope.traversing. This way people who use other traversal and publication mechanisms could still use zope.container's implementation. I think there are realistic chances alternative publication and traversal mechanisms will arise, so I think this is a realistic goal at least to consider. Let's look again at zope.container in that light. It depends on zope.publisher and zope.traversing to support traversing into the container by the publisher. The direct dependencies are: * some test depencencies. these are easiest to get rid of * bits of configuration in configure.zcml that set up the item traverser * related to that, bits of implementation in traversal.py that implement this traversal behavior. * For zope.traversal additionally some of this code is set up in zope.container.testing for reuse. If we wanted to make zope.container agnostic about traversal and the publisher, we'd need to move this code somewhere else. I cannot think of an existing package for this (anyone?). Lacking that, I'd suggest a new package, zope.containertraversing or something like that. That is one of these new packages some people object to. :) It would have a clear focus however: equipping the container with traversal behavior so it works with the zope publisher. Alternatively we could keep the code in zope.container and only enable it if zope.traversing and zope.publisher are installed, much like what Chris did with zope.app.dependable. It does worry me a little that this makes the code a bit harder to reason about however, plus it leaves a module in place people who know nothing about the publisher can still run into. Perhaps an acceptable trade off, perhaps not. Looking at zope.container, cutting out zope.publisher and zope.traversing (or making them optional) would allow us to cut the following from zope.container's dependency graph: zope.traversing zope.publisher zope.i18n zope.exceptions zope.authentication zope.browser Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.intid/trunk/ - Remove a dependency on ``zope.container.contained.Contained``
Stephan Richter wrote: > On Friday 15 May 2009, Fred Drake wrote: >> Keeping the dependency graph clean is great, and there's plenty to do >> there. But there's also something to be said about being able to keep >> a substantial portion of it in your head. The cleanliness of the >> graph isn't so important if most users still can't understand just >> because there are so many pieces that they wouldn't normally use >> directly. > > Yes, I have voiced that concern several times myself. I personally do not > even > understand where all this fear of installing many packages comes from. I > think it is because the ZCML is pulling in too many default registrations and > people are afraid of those, which I understand. But to create new packages > just because you do not want to use other parts of it is silly. That's not silly at all. I'm not afraid of installing many packages for my applications. But for libraries and little frameworks, I don't like having to depend on 70 other packages even though my library isn't using 99.9% of the code in there in any way. Is that silly? We created zope.container because we don't want to use all the code in zope.app.container. zope.app.container contains the ZMI a lot of code we don't want to be there in our apps as we're not intending to use it. Is that silly? The zope.browser package was created to prevent, among other things, z3c.form from pulling in code from zope.formlib, a completely separate form library. But it wasn't a good situation. People actually got confused and thought they had something to do with each other, in that z3c.form uses zope.formlib, which it doesn't. Is preventing that situation silly? The principle has to do more with *less code* than *less packages*. We're trying to make it possible to use and be aware of less code when considering individual chunks of the code base. To create loose coupling so that you don't have to worry about all chunks of the codebase even though you're only concerned with a little bit of it. To get rid of the code that isn't used a lot (such as the ZMI). If we can make our zope.* packages not rely on a huge amount of other packages that they aren't really using anyway, we stand a larger change understanding them ourselves, and we stand a larger change others might understand them too and adopt them. I could understand these concerns with package creation better if people would point out how the total amount of packages installed for an application or library is increasing (once the applications and libraries have been adjusted to import from the new locations). But I think the amount of packages is decreasing... Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] [Fwd: [Bug 376907] Re: AttributeError: 'str' object has no attribute 'registerSynch']
This is a bug I filed against ZODB3.9.0b1 As you can see Jim says it is a bug in zope.app.publication but there is no Launchpad project to forward the bug to for this module. The full text of the bug report is below the double lines. Thanks, Tim Forwarded Message From: Jim Fulton Reply-to: Bug 376907 <376...@bugs.launchpad.net> To: timothywayne.c...@gmail.com Subject: [Bug 376907] Re: AttributeError: 'str' object has no attribute 'registerSynch' Date: Fri, 15 May 2009 12:53:47 - This is a bug in zope.app.publication. It shouldn't pass a version to open. ** Changed in: zodb Status: New => Won't Fix == ZODB3.9.0b1 - Linux x86_64 AMD - Grok 10a3. Server starts. Creates a new Data.fs, etc. When attempting to open http://localhost:8080/applications to add my Grok apps I get this error. Traceback here: = 2009-05-15 08:30:05,890 ERROR [SiteError] http://localhost:8080 Traceback (most recent call last): File "/home/tim/.buildout/eggs/zope.publisher-3.4.6-py2.5.egg/zope/publisher/publish.py", line 129, in publish obj = publication.getApplication(request) File "/home/tim/.buildout/eggs/grok-1.0a3-py2.5.egg/grok/publication.py", line 70, in getApplication result = super(ZopePublicationSansProxy, self).getApplication(request) File "/home/tim/.buildout/eggs/zope.app.publication-3.4.3-py2.5.egg/zope/app/publication/zopepublication.py", line 150, in getApplication conn = self.db.open(version) File "/home/tim/.buildout/eggs/ZODB3-3.9.0b1-py2.5-linux-x86_64.egg/ZODB/DB.py", line 759, in open result.open(transaction_manager) File "/home/tim/.buildout/eggs/ZODB3-3.9.0b1-py2.5-linux-x86_64.egg/ZODB/Connection.py", line 1052, in open transaction_manager.registerSynch(self) AttributeError: 'str' object has no attribute 'registerSynch' === signature.asc Description: This is a digitally signed message part ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.container analysis
On Friday 15 May 2009, Martijn Faassen wrote: > It's tempting to start pushing more interfaces (and exceptions) down > into zope.browser to break dependencies further. It does run the risk of > turning zope.browser into a bit of a mash though. Perhaps that's worth > it. Opinions, anyone? zope.browser should not become an iface garbage collector. I think that interfaces not related to browser code deserve a new interfaces package. On the other hand we could rename zope.browser to zope.common or so. Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter" ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.intid/trunk/ - Remove a dependency on ``zope.container.contained.Contained``
On Friday 15 May 2009, Fred Drake wrote: > Keeping the dependency graph clean is great, and there's plenty to do > there. But there's also something to be said about being able to keep > a substantial portion of it in your head. The cleanliness of the > graph isn't so important if most users still can't understand just > because there are so many pieces that they wouldn't normally use > directly. Yes, I have voiced that concern several times myself. I personally do not even understand where all this fear of installing many packages comes from. I think it is because the ZCML is pulling in too many default registrations and people are afraid of those, which I understand. But to create new packages just because you do not want to use other parts of it is silly. Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter" ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.intid/trunk/ - Remove a dependency on ``zope.container.contained.Contained``
Fred Drake wrote: > On Fri, May 15, 2009 at 2:57 AM, Chris McDonough wrote: >> It's a partial step towards getting rid of a dependency that zope.intid has >> on >> zope.container. I'm thinking that maybe that IContained interface belongs in >> some other package (e.g. maybe zope.contained). That Container base class >> is.. >> uh.. not complicated, so even if we never do get rid of the zope.container >> dependency completely, it really doesn't harm anything to not use Contained. >> Unless you have some nostalgia for it. ;-) > > At the rate we're going, every class and every interface is going to > be in a separate package. I don't think we have many examples of this. We have zope.browser as a repository of some interfaces. The other such package off the top of my head is zope.broken, and that one really isn't pulling its weight so I hope the IBroken interface can eventually move elsewhere. (someone, analysis please? perhaps we need a package to hold content-specific interfaces, equivalent to zope.browser. IBroken and IContained might move there.. but see below) There hasn't been a lot of splitting off of classes into new packages as far as I know. We moved a lot from zope.app into zope. to leave the ZMI behind, but I don't think that's been a bad exercise at all. > Keeping the dependency graph clean is great, and there's plenty to do > there. But there's also something to be said about being able to keep > a substantial portion of it in your head. Those two goals are not mutually exclusive and in fact mutually supportive. It's not like it was easy to keep a portion in your head before this work started anyway - it was a horrible, horrible, horrible mess. http://faassen.n--tree.net/blog/view/weblog/2009/01/29/0 I'd argue it's easier now that we can actually *read* the graphs. :) > The cleanliness of the > graph isn't so important if most users still can't understand just > because there are so many pieces that they wouldn't normally use > directly. I appreciate that point. We shouldn't be generating a lot of small pieces if we can help it. That's why it is important as a first impulse to look at existing packages to move an interface into. Sometimes a dependency inversion is the right way forward. I think in the case of IContained it wouldn't hurt us much moving this interface to zope.location, as IContained is just a marker. It's not as clean as we'd like, but the dependency graph will be much cleaner if we do and it's not horrible either. We want both less packages and cleaner dependencies. I don't think we're moving in the wrong direction at present though, so I don't think it's the time to pull on the package-generation breaks just yet. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 8 OK
Summary of messages to the zope-tests list. Period Thu May 14 12:00:00 2009 UTC to Fri May 15 12:00:00 2009 UTC. There were 8 messages: 8 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Thu May 14 20:54:45 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011707.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Thu May 14 20:57:05 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011708.html Subject: OK : Zope-trunk Python-2.4.6 : Linux From: Zope Tests Date: Thu May 14 20:59:06 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011709.html Subject: OK : Zope-trunk Python-2.5.4 : Linux From: Zope Tests Date: Thu May 14 21:01:06 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011710.html Subject: OK : Zope-trunk Python-2.6.1 : Linux From: Zope Tests Date: Thu May 14 21:03:06 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011711.html Subject: OK : Zope-trunk-alltests Python-2.4.6 : Linux From: Zope Tests Date: Thu May 14 21:05:06 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011712.html Subject: OK : Zope-trunk-alltests Python-2.5.4 : Linux From: Zope Tests Date: Thu May 14 21:07:07 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011713.html Subject: OK : Zope-trunk-alltests Python-2.6.1 : Linux From: Zope Tests Date: Thu May 14 21:09:07 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011714.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.intid/trunk/ - Remove a dependency on ``zope.container.contained.Contained``
Chris McDonough wrote: > On 5/15/09 2:46 AM, Michael Howitz wrote: >> Am 15.05.2009 um 05:32 schrieb Chris McDonough: >> >>> Log message for revision 99961: >>> - Remove a dependency on ``zope.container.contained.Contained`` >>> (this is a dumb base class that defines __parent__ and __name__ >>> as None and declares that the class implements IContained). >> What's the reason behind this refactoring? >> Instead of zope.container.contained.Contained the IntIds class now >> depends on zope.container.interface.IContained plus it redefines the >> things which are already defined in zope.container.contained.Contained. >> I do not see why this is better than using the base class. > > It's a partial step towards getting rid of a dependency that zope.intid has > on > zope.container. I'm thinking that maybe that IContained interface belongs in > some other package (e.g. maybe zope.contained). That Container base class > is.. > uh.. not complicated, so even if we never do get rid of the zope.container > dependency completely, it really doesn't harm anything to not use Contained. > Unless you have some nostalgia for it. ;-) Agreed with Chris; IContained interface is very minor and it's easy enough to reimplement. If that helps us reduce dependencies I say let's not worry about this step. We might consider moving IContained to zope.location - it just subclasses from ILocation after all and doesn't add anything besides being a marker interface. zope.intid already depends on zope.location. The Contained implementation could even move to zope.location, actually. Hm, I wonder what code actually *depends* on IContained (instead implements it). Thanks Michael for watching the checkins carefully. Do keep bringing up whatever issue you see here and we'll discuss it. Even if the checkin stands, it can lead to useful discussions nonetheless. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] movedaddedremoved branches of zope.container and zope.lifecycleevent
Hanno Schlichting wrote: > Chris McDonough wrote: >> I've created two codependent branches of zope.container and >> zope.lifecyclevent: > > [...] > >> I don't know if merging this stuff is reasonable. I do understand the >> difference between "lifecycle events" and "container events" and the events >> I >> moved out are definitely container events. I just wonder if it matters to >> be >> completely correct terminology-wise here. The other alternative is to >> create >> another package. > > +1 on merging. > > I found it rather annoying so far to look for these interfaces in > different places. To me it belongs to the lifecycle of an object to be > part of a container. +1 too. Even though formally it might indeed be that these events are only container related, I did have the same frustration Hanno describes - these are very common events and often you want to subscribe to them and IObjectModified which is already in zope.lifecyclevents. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.app.publication dependencies (volunteersneeded!)
Michael Howitz wrote: > Am 14.05.2009 um 15:02 schrieb Martijn Faassen: psnip] >> Is this replacement compatible with zope.formlib's namedtemplate >> mechanism? Will anything break? > > No it is not compatible. So I think it's a bad idea. Ah, all right, glad we agree. > Breaking the > dependency between zope.app.publication and zope.app.exception by > moving the ISystemErrorView interface and maybe the class which > implements it to zope.browser would be better. I'll look into it at > weekend. Thanks! [snip] >> I understand. Why not move the namedtemplate mechanism somewhere else >> entirely, though? This way we'd not introduce new code. The >> namedtemplate code itself only seems to depend on zope.traversing, but >> that doesn't sound like a good home. The tests depend on >> zope.app.pagetemplate, so perhaps it should move there? This is >> still a >> dependency of zope.app.exception anyway, and it itself doesn't >> appear to >> depend on zope.formlib. > > Nice idea. I'll look into it. Cool. It would seem to make sense that the named template mechanism is bundled along with the page template library anyway (instead of the form library). zope.formlib currently depends on zope.app.pagetemplate too so we could easily leave a backwards compatibility import in place. zope.app.pagetemplate might be worth our further attention later, but this at least would clean up a bit more mess as a first step. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.container analysis
Hey, Chris McDonough wrote: > On 5/14/09 11:05 PM, Chris McDonough wrote: >> zope.container (32 transitive dependencies) has some possibly low-hanging >> dependency tease-apart fruit. Does anyone have any ideas about to sort out >> the >> below, particularly with externalizing the mentioned interface dependencies? >> >> - It depends on zope.filerepresentation but depends only on its interfaces >> IReadDirectory, IWriteDirectory, and IDirectoryFactory. >> (zope.filerepresentation has 32 transitive dependencies). > > I found out that zope.container<->zope.filerepresentation is a direct > circular > dependency and that zope.filerepresentation is a package containing only > interfaces. So breaking this dependency won't get us much for zope.container. I should've read on before I gave you the same answer. :) We found this out during our analysis during the dependency refactoring sprint we had a few months ago. In this I find graphs an invaluable tool, especially sccmap which I mentioned just now in another reply. > OTOH, breaking zope.filerepresentation's dependency on zope.container might > be a > win (I dont know what else depends on zope.filerepresentation). That I don't know. I don't expect it's much, however, as otherwise zope.filerepresentation would've seen seen in larger cycles during sccmap analysis. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.* package dependencies report
Hey Chris, Thanks very much for doing this analysis and work! Chris McDonough wrote: > FWIW, this may not be useful to some, but here's a (not-very-detailed) report > on > all the zope.* packages in Zope's SVN and the number of transitive > dependencies > they have. They are sorted in the order of most-dependencies-to-fewest. > > zope.introspectorui/trunk/ OK (96 dependencies) I don't think this is actually in use by anyone (remnant of last year's summer of code project that didn't end up going anywhere far), so we can safely ignore this monster. :) > A lot of nice work since the last time I did this (mid-2007 or so), when a > lot > of these packages pulled in "the world". Thanks. Work really started taking off in the beginning of this year, and a lot of people have pitched in. Regards, Martijn P.S. You might be interested in looking at z3c.recipe.depgraph. For some reason its sccmap tool spits out unreadable graphs now though, and graphviz's sccmap reduction of graphs to cycles is one of the most useful tools I've found so far in doing this kind of analysis. Not sure what's going on there. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.container analysis
Hey, Chris McDonough wrote: > zope.container (32 transitive dependencies) has some possibly low-hanging > dependency tease-apart fruit. Does anyone have any ideas about to sort out > the > below, particularly with externalizing the mentioned interface dependencies? > > - It depends on zope.filerepresentation but depends only on its interfaces >IReadDirectory, IWriteDirectory, and IDirectoryFactory. >(zope.filerepresentation has 32 transitive dependencies). Heh, zope.filerepresentation has 32 transitive dependencies because they're zope.container's. :) (the only other dependency is has it zope.interface). There's a simple cycle from filerepresentation to container and back. When we looked at them last it's not clear how to resolve them cleanly. Suggestions from anyone? Anyway, this cycle isn't a dramatic one as it only keeps this one package alive. > - It depends on zope.app.dependable but depends only on its interfaces >IDependable and DependencyError. (note: zope.app.dependable might >be a candidate to be called zope.dependable as it depends on no other > zope.app >packages; it does depend on about 20 other zope.* packages transitively > tho). Looking at the graph here: http://startifact.com/depgraphs/zope.container.svg It looks like zope.app.dependable most depends directly on things zope.container depends on through other routes anyway. The exception is zope.annotation. I see you removed the dependency on zope.app.dependable partially by making it conditional. That looks reasonable and should cut out zope.annotation as well. > - It depends on zope.publisher, but only its interfaces > browser.IBrowserRequest, >browser.IBrowserPublisher, NotFound, IDefaultViewName, >xmlrpc.IXMLRPCPublisher, and IPublishTraverse. > > - I was able to break a runtime logic dependency on zope.traversing by >disusing zope.traversing.api.getPath in favor of using >ILocationInfo(object).getPath(). The rest of the runtime dependencies on >zope.traversing are interface dependencies (ITraversable, > IContainmentRoot). It's tempting to start pushing more interfaces (and exceptions) down into zope.browser to break dependencies further. It does run the risk of turning zope.browser into a bit of a mash though. Perhaps that's worth it. Opinions, anyone? Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.app.publication dependencies (volunteers needed!)
Hey, Chris McDonough wrote: [snip a lot of places where these interfaces are used] I'm sure these interfaces are used all over the place as they're used to help implement widgets; we can't just remove them from their original location, but... > It's also apparently documented in Phillip's book. So... what? E... I > dunno. The interfaces are: > > from zope.app.form.interfaces import IInputWidget, IDisplayWidget > from zope.app.form.interfaces import InputErrors, WidgetInputError > from zope.app.form.browser.interfaces import IWidgetImportErrorView > > Any thoughts? What would happen if we moved them to zope.formlib and left backwards compatibility imports in place in zope.app.formlib? I think it makes sense for zope.formlib to specify its widget interfaces, and zope.app.form to implement a bunch of those widgets. We can also consider (possibly as a separate later step) moving at least some widget implementations themselves into zope.formlib and just leave the old ZCML form stuff behind in zope.app.form (and a lot of backward compat code). We should only move those things into zope.formlib that don't increase its dependencies though, so we can't move everything. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.app.publication dependencies (volunteers needed!)
Hey, Hanno Schlichting wrote: > This is part of the whole named template adapter story. The rationale > for the whole story is to be able to replace the template of a view > without touching the view. So the template is looked up as an adapter > and not just accessed as self.index / self.template. Personally I find > the whole feature just annoying and overcomplicated. I think the whole > feature is due for removal. It's only used in a very minor number of > cases and not consistently with views in general. Could you comment on the discussion I've had with Michael Howitz elsewhere in this thread about this then? I think this relates to the whole z3c.template and zope.formlib discussion. [suggestion to invert the dependency between zope.formlib and zope.app.form] Ah, great minds... Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.app.publication dependencies (volunteers needed!)
Hey, Chris McDonough wrote: > I did a bit of research on the direct "zope.app.*" dependencies of > zope.formlib. Cool! > - I looked into its dependency on zope.app.form. It >essentially uses a bunch of interfaces from the >zope.app.form.interfaces package. I don't know whether it >would be reasonable to move all those interfaces >to zope.browser or somewhere else, but essentially >moving those interfaces to somewhere "neutral" >would break this particular dependency. I think it might make sense to reverse these dependencies - i.e. zope.app.form uses interfaces from zope.formlib for implementing its widgets. The old ZCML-based form mechanism in zope.app.form is moribund anyway so we can just ignore that. Don't know whether this would help the dependency structures though. I think it's going to be hard to motivate moving zope.app.form interfaces to zope.browser, as ideally we'd like to make the rest of the toolkit unaffected by particular decisions on how form generation should work. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.recipe.i18n tests break on unix
Am 15.05.2009 um 12:36 schrieb Christian Zagrodnick: [...] > Okay, would you give me the pypi access (user zagy)? Done. Yours sincerely, -- Michael Howitz · m...@gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.recipe.i18n tests break on unix
Am 15.05.2009 um 11:40 schrieb Christian Zagrodnick:
> Hi,
>
> the tests of z3c.reipce.i18n break on unix systems, for instance with:
>
> Failed example:
>ls('bin')
> Expected:
>- buildout-script.py
>- buildout.exe
>- i18ncompile-script.py
>- i18ncompile.exe
>- i18nextract-script.py
>- i18nextract.exe
>- i18nmergeall-script.py
>- i18nmergeall.exe
>- i18nstats-script.py
>- i18nstats.exe
> Got:
>- buildout
>- i18ncompile
>- i18nextract
>- i18nmergeall
>- i18nstats
>
>
> What's the general way of testing those things in both environments? I
> don't have a windows box to test this. I also see most recipes are
> tested only for unix (which would be fine for me).
In z3c.recipe.paster I solved this with two re normalizers, see
http://tinyurl.com/ofc6nx lines 115 and 116.
Yours sincerely,
--
Michael Howitz · m...@gocept.com · software developer
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1
Zope and Plone consulting and development
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.recipe.i18n tests break on unix
On 2009-05-15 12:16:30 +0200, "Roger Ineichen" said: > Hi Christian > >> What's the general way of testing those things in both > >> environments? I don't have a windows box to test this. I also > >> see most recipes are tested only for unix (which would be > >> fine for me). >> > >> How should we proceed in this special case? Actually there is > >> a bug which I'm going to fix w/o having passing tests now. > > I'm fine if you switch the tests that they pass on linux and > will break on windows. I can catchup the tests later and try > to make them running again on windows and linux. Okay, would you give me the pypi access (user zagy)? > > Thanks a lot for help improve missing parts or fix issues! np, after all I want to use it :) -- Christian Zagrodnick · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.intid/trunk/ - Remove a dependency on ``zope.container.contained.Contained``
On Fri, May 15, 2009 at 2:57 AM, Chris McDonough wrote: > It's a partial step towards getting rid of a dependency that zope.intid has on > zope.container. I'm thinking that maybe that IContained interface belongs in > some other package (e.g. maybe zope.contained). That Container base class > is.. > uh.. not complicated, so even if we never do get rid of the zope.container > dependency completely, it really doesn't harm anything to not use Contained. > Unless you have some nostalgia for it. ;-) At the rate we're going, every class and every interface is going to be in a separate package. Keeping the dependency graph clean is great, and there's plenty to do there. But there's also something to be said about being able to keep a substantial portion of it in your head. The cleanliness of the graph isn't so important if most users still can't understand just because there are so many pieces that they wouldn't normally use directly. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.recipe.i18n tests break on unix
Hi Christian
> Betreff: [Zope-dev] z3c.recipe.i18n tests break on unix
>
> Hi,
>
> the tests of z3c.reipce.i18n break on unix systems, for instance with:
>
> Failed example:
> ls('bin')
> Expected:
> - buildout-script.py
> - buildout.exe
> - i18ncompile-script.py
> - i18ncompile.exe
> - i18nextract-script.py
> - i18nextract.exe
> - i18nmergeall-script.py
> - i18nmergeall.exe
> - i18nstats-script.py
> - i18nstats.exe
> Got:
> - buildout
> - i18ncompile
> - i18nextract
> - i18nmergeall
> - i18nstats
>
>
> What's the general way of testing those things in both
> environments? I don't have a windows box to test this. I also
> see most recipes are tested only for unix (which would be
> fine for me).
>
> How should we proceed in this special case? Actually there is
> a bug which I'm going to fix w/o having passing tests now.
I'm fine if you switch the tests that they pass on linux and
will break on windows. I can catchup the tests later and try
to make them running again on windows and linux.
Thanks a lot for help improve missing parts or fix issues!
Regards
Roger Ineichen
> Regards,
> --
> Christian Zagrodnick · c...@gocept.com
> gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale)
> · germany http://gocept.com · tel +49 345 1229889 4 · fax +49
> 345 1229889 1 Zope and Plone consulting and development
>
>
> ___
> Zope-Dev maillist - Zope-Dev@zope.org
> http://mail.zope.org/mailman/listinfo/zope-dev
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://mail.zope.org/mailman/listinfo/zope-announce
> http://mail.zope.org/mailman/listinfo/zope )
>
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] z3c.recipe.i18n tests break on unix
Hi,
the tests of z3c.reipce.i18n break on unix systems, for instance with:
Failed example:
ls('bin')
Expected:
- buildout-script.py
- buildout.exe
- i18ncompile-script.py
- i18ncompile.exe
- i18nextract-script.py
- i18nextract.exe
- i18nmergeall-script.py
- i18nmergeall.exe
- i18nstats-script.py
- i18nstats.exe
Got:
- buildout
- i18ncompile
- i18nextract
- i18nmergeall
- i18nstats
What's the general way of testing those things in both environments? I
don't have a windows box to test this. I also see most recipes are
tested only for unix (which would be fine for me).
How should we proceed in this special case? Actually there is a bug
which I'm going to fix w/o having passing tests now.
Regards,
--
Christian Zagrodnick · c...@gocept.com
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone consulting and development
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] movedaddedremoved branches of zope.container and zope.lifecycleevent
Chris McDonough wrote: > I've created two codependent branches of zope.container and > zope.lifecyclevent: [...] > I don't know if merging this stuff is reasonable. I do understand the > difference between "lifecycle events" and "container events" and the events I > moved out are definitely container events. I just wonder if it matters to be > completely correct terminology-wise here. The other alternative is to create > another package. +1 on merging. I found it rather annoying so far to look for these interfaces in different places. To me it belongs to the lifecycle of an object to be part of a container. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.container analysis
Chris McDonough wrote: > On 5/14/09 11:05 PM, Chris McDonough wrote: >> >> - It depends on zope.filerepresentation but depends only on its interfaces >> IReadDirectory, IWriteDirectory, and IDirectoryFactory. >> (zope.filerepresentation has 32 transitive dependencies). > > I found out that zope.container<->zope.filerepresentation is a direct > circular > dependency and that zope.filerepresentation is a package containing only > interfaces. So breaking this dependency won't get us much for > zope.container. > OTOH, breaking zope.filerepresentation's dependency on zope.container might > be a > win (I dont know what else depends on zope.filerepresentation). > zope.filerepresentation depends only on > zope.container.interfaces.IReadContainer > and zope.container.interfaces.IWriteContainer. I'd favor moving the interfaces from zope.filerepresentation into zope.container itself and abandoning the zope.filerepresentation package. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] movedaddedremoved branches of zope.container and zope.lifecycleevent
I've created two codependent branches of zope.container and zope.lifecyclevent: http://svn.zope.org/zope.container/branches/movedaddedremoved/ http://svn.zope.org/zope.lifecycleevent/branches/movedaddedremoved/ The intent was to move ``IObjectMovedEvent``, ``IObjectAddedEvent``, ``IObjectRemovedEvent`` interfaces and ``ObjectMovedEvent``, ``ObjectAddedEvent`` and ``ObjectRemovedEvent`` to the ``zope.lifecycleevent`` event package. Merging this would allow us to reduce dependencies on zope.container in other packages (instead, those packages would just depend on zope.lifecycleevent, which has very few dependencies). zope.intid is one such package (although it still will have one niggling dependency on "IContained" from zope.container even after it started to import event stuff from zope.lifecycleevent) I don't know if merging this stuff is reasonable. I do understand the difference between "lifecycle events" and "container events" and the events I moved out are definitely container events. I just wonder if it matters to be completely correct terminology-wise here. The other alternative is to create another package. - C ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.app.publication dependencies (volunteersneeded!)
Am 14.05.2009 um 15:02 schrieb Martijn Faassen: > Michael Howitz wrote: >> Am 14.05.2009 um 12:05 schrieb Martijn Faassen: > [snip] >>> Could you talk a bit about what your branch is trying to accomplish? >> >> zope.app.exception depends on zope.formlib's namedtemplate mechanism. >> zope.formlib has many many dependencies but only this special >> function >> of it is used by zope.app.exception. It's needed to render >> customizable the unauthorized views. >> So I replaced zope.formlib by the much more lightweight z3c.template. > > Is this replacement compatible with zope.formlib's namedtemplate > mechanism? Will anything break? No it is not compatible. So I think it's a bad idea. Breaking the dependency between zope.app.publication and zope.app.exception by moving the ISystemErrorView interface and maybe the class which implements it to zope.browser would be better. I'll look into it at weekend. > The guaranteed compatible step forward to reduce dependencies would be > to extract the namedtemplate mechanism from zope.formlib and place > that > somewhere else. zope.formlib can then have an import for backwards > compatibility. Maybe, but is this namedtemplate mechanism used outside zope.formlib? If so we should extract it. >> See also the proposal >> http://mail.zope.org/pipermail/zope-dev/2009-April/035833.html > > I missed this discussion then, my apologies. I still stand by my > opinion > that this would suddenly pull in *new* libraries in with a significant > chunk of new code, and we need to be very careful with that and not > just > do it to lift a dependency. Right. I will not merge my branch, but look into breaking the zope.app.publisher dependency. >>> (see elsewhere on the thread for a way to cut the dependency of >>> zope.app.publication to zope.app.exception completely with little >>> effort) >> >> This (move the ISystemErrorView) seems to be the right solution to >> get >> rid of the zope.app.publication dependency on zope.app.exception. >> In a project of mine I need zope.app.exception independently of this >> dependency but I do not want to depend on zope.formlib for a little >> feature of it which can be done by another smaller package. I looked into it, its not a project of mine it's z3c.layer.pagelet but it can be refactored to use only the ISystemErrorView interface. It uses some classes from zope.app.exception but does not need their features. So I'll refactor it. > I understand. Why not move the namedtemplate mechanism somewhere else > entirely, though? This way we'd not introduce new code. The > namedtemplate code itself only seems to depend on zope.traversing, but > that doesn't sound like a good home. The tests depend on > zope.app.pagetemplate, so perhaps it should move there? This is > still a > dependency of zope.app.exception anyway, and it itself doesn't > appear to > depend on zope.formlib. Nice idea. I'll look into it. > zope.app.exception's UI bits are a curious case in that they're not > really part of the ZMI, though they integrate with the ZMI and assume > the existence of some macros. It's also a zope.app.* package and we'd > like to get rid of those in the toolkit. What to do with it? Yours sincerely, -- Michael Howitz · m...@gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
