Re: [Zope-dev] Grok cave sprint summary, and future todos
2009/1/31 Martijn Faassen : > Dan Korostelev wrote: >> Also, there's a bug in zope.traversing: >> >> The getParents function of zope.traversing.api uses the "getParents" >> method of IPhysicallyLocatable, which really is new ILocationInfo, but >> this interface doesn't even declare getParents method and the >> RootPhysicallyLocatable adapter in zope.traversing doesn't implement >> it as well so I got errors. :-/ > > Oops, none of the tests caught that somehow, where'd you get the errors? > > Anyway, Christian Theune should be back online soon to help resolve this > one. I checked out the adapters myself and it looks like the RootPhysicallyLocatable works exactly like the default LocationPhysicallyLocatable would work for the IRoot object. So I propose to remove the RootPhysicallyLocatable implementation from zope.traversing.adapters and import LocationPhyscallyLocatable as RootPhysicallyLocatable there and remove its registration from zope.traversing's configure.zcml. And, of course, the getParents method should be added to the ILocationInfo interface and that should be stated in changelog somehow, because that's an extension to API requirements, so third-party components will need to implement that method in their custom implementations, if there are any. -- WBR, Dan Korostelev ___ 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] Grok cave sprint summary, and future todos
2009/1/31 Martijn Faassen : > Dan Korostelev wrote: >> Also, there's a bug in zope.traversing: >> >> The getParents function of zope.traversing.api uses the "getParents" >> method of IPhysicallyLocatable, which really is new ILocationInfo, but >> this interface doesn't even declare getParents method and the >> RootPhysicallyLocatable adapter in zope.traversing doesn't implement >> it as well so I got errors. :-/ > > Oops, none of the tests caught that somehow, where'd you get the errors? Well, getParents function got used for the root object by z3c.breadcrumb in my application. :) > Anyway, Christian Theune should be back online soon to help resolve this > one. This case should be added in tests. I think zope.interface.verify.verifyObject will catch errors like that. -- WBR, Dan Korostelev ___ 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] Grok cave sprint summary, and future todos
Hey, Dan Korostelev wrote: > That's a great piece of work you did, thanks! > > I've been following package releases and have noticed some mistakes > mainly in changelog formatting: > >> zope.proxy >> = >> >> 3.5.0 (unreleased) >> >> * Added support to bootstrap on Jython. >> * Use zope.container instead of zope.app.container. > > Well, it IS released :) Also it doesn't really "use" zope.container or > zope.app.container, there's just a comment in the .c file :) Oops, fixed it. >> zope.dublincore >> = >> >> 3.4.2 (unreleased) >> 3.4.1 (2009-01-26) > > Again, it IS released. Also some changelog entry is missing :) Fixed too now. I must've accidentally tagged before I made some more changes in the release notes. Easy to make mistakes when doing so many releases, thanks for catching them! 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] Grok cave sprint summary, and future todos
Dan Korostelev wrote: > Also, there's a bug in zope.traversing: > > The getParents function of zope.traversing.api uses the "getParents" > method of IPhysicallyLocatable, which really is new ILocationInfo, but > this interface doesn't even declare getParents method and the > RootPhysicallyLocatable adapter in zope.traversing doesn't implement > it as well so I got errors. :-/ Oops, none of the tests caught that somehow, where'd you get the errors? Anyway, Christian Theune should be back online soon to help resolve this one. 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] Grok cave sprint summary, and future todos
Also, there's a bug in zope.traversing:
The getParents function of zope.traversing.api uses the "getParents"
method of IPhysicallyLocatable, which really is new ILocationInfo, but
this interface doesn't even declare getParents method and the
RootPhysicallyLocatable adapter in zope.traversing doesn't implement
it as well so I got errors. :-/
2009/1/31 Dan Korostelev :
> Hi!
>
> That's a great piece of work you did, thanks!
>
> I've been following package releases and have noticed some mistakes
> mainly in changelog formatting:
>
>> zope.proxy
>> =
>>
>> 3.5.0 (unreleased)
>>
>> * Added support to bootstrap on Jython.
>> * Use zope.container instead of zope.app.container.
>
> Well, it IS released :) Also it doesn't really "use" zope.container or
> zope.app.container, there's just a comment in the .c file :)
>
>> zope.dublincore
>> =
>>
>> 3.4.2 (unreleased)
>> 3.4.1 (2009-01-26)
>
> Again, it IS released. Also some changelog entry is missing :)
>
> Also, please, check the buildout.cfg of the zope.container, because it
> still includes some local developer develop paths and recipes.
>
> 2009/1/31 Martijn Faassen :
>> Hi there,
>>
>> I've just made a lot of releases as the result of our dependency cleanup
>> sprint. There are more releases to be made, but I think I've released
>> the most important affected packages now. Christian Theune is going to
>> follow up and release some more packages that we touched, probably tomorrow.
>>
>> I'm going to write up a document that describes how we analyzed
>> dependencies and what approaches we took so that people who want to help
>> have some idea of what to do.
>>
>> the most important affected packages are (as far as I can remember):
>>
>> zope.app.component ('class' ZCML directive moved into zope.security,
>> site stuff extracted into zope.site)
>>
>> zope.app.security ('module' directive moved into zope.security, along
>> with some helper functions)
>>
>> zope.app.container (most functionality moved into zope.container)
>>
>> zope.app.folder (base class moved into zope.container, Folder itself
>> moved into zope.site as its main function was to mix in site management
>> facilities)
>>
>> zope.traversing (depends on zope.location now instead of the other way
>> around)
>>
>> zope.location (doesn't depend on zope.traversing anymore)
>>
>> zope.site (a new package extracted from zope.app.component and
>> zope.app.folder)
>>
>> zope.container (a new package extracted from zope.app.container and
>> zope.app.folder)
>>
>> Another thing we want to do is reduce the test dependencies of packages
>> to almost nothing (or nothing at all). We think it'd be good if package
>> only used what they depend on directly for testing purposes; testing
>> dependencies in general should follow implementation dependencies. This
>> might allow us to get rid of zope.app.testing at some point. Instead
>> we'd like to see more (and more consistent!) 'testing' modules in
>> packages that help with test setup.
>>
>> We have created a bunch of tools in the process of reducing
>> dependencies: an extension to the test runner to track imports that
>> could be modified to be from a better location (though 'grep' is very
>> useful there too), z3c.recipe.compattest, and Christian Theune is
>> working on a way to 'touch' the ZODB so that it will update any moved
>> class to the new location.
>>
>> Note that we haven't finished going through the codebase changing
>> imports from zope.app.folder to zope.site where possible - volunteers
>> are welcome. This should further reduce dependencies in the entire graph
>> as zope.site pulls in far less than zope.app.folder.
>>
>> If a bunch of us keep this up we'll that'll allow us to start retiring a
>> lot of packages that are mostly unused, and have a smaller, easier set
>> of Zope 3 packages to maintain and understand. Users of the Zope 3
>> libraries (plain Zope 3, Grok, Zope 2, Repoze, and others) should all
>> benefit from this.
>>
>> 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 )
>>
>
>
>
> --
> WBR, Dan Korostelev
>
--
WBR, Dan Korostelev
___
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] Grok cave sprint summary, and future todos
Hi!
That's a great piece of work you did, thanks!
I've been following package releases and have noticed some mistakes
mainly in changelog formatting:
> zope.proxy
> =
>
> 3.5.0 (unreleased)
>
> * Added support to bootstrap on Jython.
> * Use zope.container instead of zope.app.container.
Well, it IS released :) Also it doesn't really "use" zope.container or
zope.app.container, there's just a comment in the .c file :)
> zope.dublincore
> =
>
> 3.4.2 (unreleased)
> 3.4.1 (2009-01-26)
Again, it IS released. Also some changelog entry is missing :)
Also, please, check the buildout.cfg of the zope.container, because it
still includes some local developer develop paths and recipes.
2009/1/31 Martijn Faassen :
> Hi there,
>
> I've just made a lot of releases as the result of our dependency cleanup
> sprint. There are more releases to be made, but I think I've released
> the most important affected packages now. Christian Theune is going to
> follow up and release some more packages that we touched, probably tomorrow.
>
> I'm going to write up a document that describes how we analyzed
> dependencies and what approaches we took so that people who want to help
> have some idea of what to do.
>
> the most important affected packages are (as far as I can remember):
>
> zope.app.component ('class' ZCML directive moved into zope.security,
> site stuff extracted into zope.site)
>
> zope.app.security ('module' directive moved into zope.security, along
> with some helper functions)
>
> zope.app.container (most functionality moved into zope.container)
>
> zope.app.folder (base class moved into zope.container, Folder itself
> moved into zope.site as its main function was to mix in site management
> facilities)
>
> zope.traversing (depends on zope.location now instead of the other way
> around)
>
> zope.location (doesn't depend on zope.traversing anymore)
>
> zope.site (a new package extracted from zope.app.component and
> zope.app.folder)
>
> zope.container (a new package extracted from zope.app.container and
> zope.app.folder)
>
> Another thing we want to do is reduce the test dependencies of packages
> to almost nothing (or nothing at all). We think it'd be good if package
> only used what they depend on directly for testing purposes; testing
> dependencies in general should follow implementation dependencies. This
> might allow us to get rid of zope.app.testing at some point. Instead
> we'd like to see more (and more consistent!) 'testing' modules in
> packages that help with test setup.
>
> We have created a bunch of tools in the process of reducing
> dependencies: an extension to the test runner to track imports that
> could be modified to be from a better location (though 'grep' is very
> useful there too), z3c.recipe.compattest, and Christian Theune is
> working on a way to 'touch' the ZODB so that it will update any moved
> class to the new location.
>
> Note that we haven't finished going through the codebase changing
> imports from zope.app.folder to zope.site where possible - volunteers
> are welcome. This should further reduce dependencies in the entire graph
> as zope.site pulls in far less than zope.app.folder.
>
> If a bunch of us keep this up we'll that'll allow us to start retiring a
> lot of packages that are mostly unused, and have a smaller, easier set
> of Zope 3 packages to maintain and understand. Users of the Zope 3
> libraries (plain Zope 3, Grok, Zope 2, Repoze, and others) should all
> benefit from this.
>
> 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 )
>
--
WBR, Dan Korostelev
___
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] Grok cave sprint summary, and future todos
Hi there,
I've just made a lot of releases as the result of our dependency cleanup
sprint. There are more releases to be made, but I think I've released
the most important affected packages now. Christian Theune is going to
follow up and release some more packages that we touched, probably tomorrow.
I'm going to write up a document that describes how we analyzed
dependencies and what approaches we took so that people who want to help
have some idea of what to do.
the most important affected packages are (as far as I can remember):
zope.app.component ('class' ZCML directive moved into zope.security,
site stuff extracted into zope.site)
zope.app.security ('module' directive moved into zope.security, along
with some helper functions)
zope.app.container (most functionality moved into zope.container)
zope.app.folder (base class moved into zope.container, Folder itself
moved into zope.site as its main function was to mix in site management
facilities)
zope.traversing (depends on zope.location now instead of the other way
around)
zope.location (doesn't depend on zope.traversing anymore)
zope.site (a new package extracted from zope.app.component and
zope.app.folder)
zope.container (a new package extracted from zope.app.container and
zope.app.folder)
Another thing we want to do is reduce the test dependencies of packages
to almost nothing (or nothing at all). We think it'd be good if package
only used what they depend on directly for testing purposes; testing
dependencies in general should follow implementation dependencies. This
might allow us to get rid of zope.app.testing at some point. Instead
we'd like to see more (and more consistent!) 'testing' modules in
packages that help with test setup.
We have created a bunch of tools in the process of reducing
dependencies: an extension to the test runner to track imports that
could be modified to be from a better location (though 'grep' is very
useful there too), z3c.recipe.compattest, and Christian Theune is
working on a way to 'touch' the ZODB so that it will update any moved
class to the new location.
Note that we haven't finished going through the codebase changing
imports from zope.app.folder to zope.site where possible - volunteers
are welcome. This should further reduce dependencies in the entire graph
as zope.site pulls in far less than zope.app.folder.
If a bunch of us keep this up we'll that'll allow us to start retiring a
lot of packages that are mostly unused, and have a smaller, easier set
of Zope 3 packages to maintain and understand. Users of the Zope 3
libraries (plain Zope 3, Grok, Zope 2, Repoze, and others) should all
benefit from this.
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 )
