dependency cleanup progress report
Hi there, After a lot of work we have progress to report on the dependency reduction front: http://faassen.n--tree.net/blog/view/weblog/2009/01/29/0 It's been a lot of work to get this far and there's a huge amount of work to be done still, but there is progress! The second dependency graph is against the trunks of all the packages, as we haven't done the releases yet to make this real. We will look into this tomorrow. We also need to document the various procedures we have been using to do this work so that others can jump in and help us. Regards, Martijn
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martijn Faassen wrote:
Hi there,
After a lot of work we have progress to report on the dependency reduction front:
http://faassen.n--tree.net/blog/view/weblog/2009/01/29/0
It's been a lot of work to get this far and there's a huge amount of work to be done still, but there is progress!
The second dependency graph is against the trunks of all the packages, as we haven't done the releases yet to make this real. We will look into this tomorrow. We also need to document the various procedures we have been using to do this work so that others can jump in and help us.
Excellent work! Looking at the zope.container graph: - - The zope.publisher dependency is purely there for the 'traverser.py' module, which probably doesn't belong in zope.container at all: it only imports interfaces to set up __adapts__, which suggests that it should be in zope.publisher, or some other package which depends on both (losing the __adapts__ wouldn't be terrible, for instance). - - The dependency module pulls in zope.app.dependable: I think it would make more sense to move the event subscriber *into* that package. which would remove the other, indirect dependency on zope.traversing. - - The 'testing' module should lose all the zope-specific module-scope imports, even if that means losing some convenience. - - The 'contained' module has a bunch of dependencies, including a suspicous one on zope.app.broken: if the IBroken check is really needed, then that interface should be moved to another package. - - The zope.exceptions dependency, again from contained, is due to the use of a couple of dubious zope-specific exceptions: o UserError should probably be replaced with the standard ValueError. o DuplicationError should probably be replaced with KeyError. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@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 iD8DBQFJgjDu+gerLs4ltQ4RAtv4AJ902n6ZnbpoA3patMcW8H/93cAYeACeNoeR 3XSe5cO+WIcCHz2o/TtDZkc= =6kKl -----END PGP SIGNATURE-----
Hey, Thanks for this feedback. It's a good sign that such feedback is now possible due to us having a saner dependency graph! We won't be taking action on these issues during this sprint as we're trying to wrap it up and make releases of our changes. At least the dependency graph for zope.container has no more cycles (they're still abundant elsewhere but we have a better grip on them now at least). hat shouldn't stop anyone from trying out Tres's suggestions, which all look like good ideas. When you try these things it's a good idea to test the trunks of various packages against each other, so do consider using z3c.recipe.compattest with use_trunk mode to make sure your changes don't break anything. Regards, Martijn
On Fri, Jan 30, 2009 at 3:47 PM, Martijn Faassen <faassen@startifact.com> wrote: (snip)
When you try these things it's a good idea to test the trunks of various packages against each other, so do consider using z3c.recipe.compattest with use_trunk mode to make sure your changes don't break anything.
That should be the "use_svn = true" option. regards, jw -- Jan-Wijbrand Kolman
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tres Seaver wrote:
Martijn Faassen wrote:
Hi there,
After a lot of work we have progress to report on the dependency reduction front:
It's been a lot of work to get this far and there's a huge amount of work to be done still, but there is progress!
The second dependency graph is against the trunks of all the packages, as we haven't done the releases yet to make this real. We will look into this tomorrow. We also need to document the various procedures we have been using to do this work so that others can jump in and help us.
Excellent work!
Looking at the zope.container graph:
- The zope.publisher dependency is purely there for the 'traverser.py' module, which probably doesn't belong in zope.container at all: it only imports interfaces to set up __adapts__, which suggests that it should be in zope.publisher, or some other package which depends on both (losing the __adapts__ wouldn't be terrible, for instance).
- The dependency module pulls in zope.app.dependable: I think it would make more sense to move the event subscriber *into* that package. which would remove the other, indirect dependency on zope.traversing.
- The 'testing' module should lose all the zope-specific module-scope imports, even if that means losing some convenience.
I have implemented this one by creating a new 'zope.broken' package, and making 'zope.container' and 'zope.app.broken' depend on it:
- The 'contained' module has a bunch of dependencies, including a suspicous one on zope.app.broken: if the IBroken check is really needed, then that interface should be moved to another package.
and this one:
- The zope.exceptions dependency, again from contained, is due to the use of a couple of dubious zope-specific exceptions:
o UserError should probably be replaced with the standard ValueError.
o DuplicationError should probably be replaced with KeyError.
now released in zope.container 3.7.1 and zope.app.container 3.7.1. I also updated the 'zope.app.zcmlfiles' package (now version 3.5.3), which was not including the 'zope.app.broken' package in its dependencies, although it pulls in its ZCML. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@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 iD8DBQFJiy01+gerLs4ltQ4RAhfHAJ9bhVfaH+Jw/4qEE/c1Yg3ycCl/SQCfbykt InDS4RvBO5qlJ6JPioIhE8I= =pQ0n -----END PGP SIGNATURE-----
participants (3)
-
Jan-Wijbrand Kolman -
Martijn Faassen -
Tres Seaver