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
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
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
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``,
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
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
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
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
On Fri, May 15, 2009 at 2:57 AM, Chris McDonough chr...@plope.com 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
On 2009-05-15 12:16:30 +0200, Roger Ineichen d...@projekt01.ch 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
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
-
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
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.
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
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
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
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
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
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
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
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:
Fred Drake wrote:
On Fri, May 15, 2009 at 2:57 AM, Chris McDonough chr...@plope.com 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
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
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
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
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
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.
On 5/15/09 6:27 AM, Fred Drake wrote:
On Fri, May 15, 2009 at 2:57 AM, Chris McDonoughchr...@plope.com 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.
-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
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
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
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
Thanks for this!
2009/5/14 Andreas Jung li...@zopyx.com:
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
33 matches
Mail list logo
