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 ha
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``,
``IObjectRemove
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 c
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
> - i18
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
> i
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 sh
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
>- i18nextr
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 3
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
>
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 book
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.f
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 or
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 int
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
> depende
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 e
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
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://
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). Tha
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.brow
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 Ful
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 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 z
-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
> > th
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 som
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
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.p
33 matches
Mail list logo