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
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 <faassen@startifact.com>:
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
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 <nadako@gmail.com>:
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 <faassen@startifact.com>:
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
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
2009/1/31 Martijn Faassen <faassen@startifact.com>:
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
2009/1/31 Martijn Faassen <faassen@startifact.com>:
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
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
participants (2)
-
Dan Korostelev -
Martijn Faassen