Breaking the dep cycle between zope.{container, filerepresentation}
Hello, I would like to break the dep cycle between zope.container and zope.filerepresentation. I already prepared the two patches (attached to this e-mail), but I'm not confident enough with the zope3 repository to check in them without asking for comments. Is this the right way to break the dependency? I think nobody really uses zope.filerepresentation, so transforming it into a dummy package which just imports things from zope.container.interface is ok. Thanks in advance, Fabio
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fabio Tranchitella wrote:
Hello,
I would like to break the dep cycle between zope.container and zope.filerepresentation. I already prepared the two patches (attached to this e-mail), but I'm not confident enough with the zope3 repository to check in them without asking for comments.
Is this the right way to break the dependency? I think nobody really uses zope.filerepresentation, so transforming it into a dummy package which just imports things from zope.container.interface is ok.
I think I would break the cycle by moving the IReadDirectory, IWriteDirectory, and IDirectoryFactory interfaces to zope.container: those three interfaces are used directly in zope.container, and they are "about" containers. I would leave the other two (IReadFile, IWriteFile) declared in zope.filerepresentation. We can then leave behind BBB imports in zope.filerepresentation, which will depend on zope.container for them; zope.container will no longer depend on zope.filerepresentation. 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 iD8DBQFKVAJE+gerLs4ltQ4RAp7yAKCcWI+rG2oNGVrWXWiBSXnNKb36cgCgizIV EdYKLqfwcU0kU99x2HeHmmA= =t8KD -----END PGP SIGNATURE-----
On Jul 7, 2009, at 5:15 PM, Fabio Tranchitella wrote:
Hello,
I would like to break the dep cycle between zope.container and zope.filerepresentation. I already prepared the two patches (attached to this e-mail), but I'm not confident enough with the zope3 repository to check in them without asking for comments.
Is this the right way to break the dependency? I think nobody really uses zope.filerepresentation, so transforming it into a dummy package which just imports things from zope.container.interface is ok.
zope.filerepresentation should not depend on zope.container. It is supposed to provide generic interfaces for mapping objects onto file- system representations. It would be best to change IRead/Write directory to define their attributes directly without extending zope.container interfaces. I find it a bit hard to believe that there are no clients of these interfaces, but, if that's the case, I suggest deprecating zope.filerepresentation and zope.container.directory. In that case, I'd just remove the dependency in zope.container on zope.filerepresentation. If an application is going to use zope.container.directory, it will need to import zope.filerepresentation.interfaces itself, and it will have the zope.filerepresentation dependency itself. I'd add deprecation warning in zope.container.directory. I wouldn't add these interfaces to zope.container.interfaces. Jim -- Jim Fulton Zope Corporation
Hello, * 2009-07-08 12:51, Jim Fulton wrote:
I find it a bit hard to believe that there are no clients of these interfaces, but, if that's the case, I suggest deprecating zope.filerepresentation and zope.container.directory. In that case, I'd just remove the dependency in zope.container on zope.filerepresentation. If an application is going to use zope.container.directory, it will need to import zope.filerepresentation.interfaces itself, and it will have the zope.filerepresentation dependency itself. I'd add deprecation warning in zope.container.directory. I wouldn't add these interfaces to zope.container.interfaces.
What about adding zope.filerepresentation as an extras_require "directory"? If somebody is using zope.container.directory, it is possible to depend on zope.container [directory]. Best regards. -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _____________________________________________________________________ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564
On Jul 8, 2009, at 8:21 AM, Fabio Tranchitella wrote:
Hello,
* 2009-07-08 12:51, Jim Fulton wrote:
I find it a bit hard to believe that there are no clients of these interfaces, but, if that's the case, I suggest deprecating zope.filerepresentation and zope.container.directory. In that case, I'd just remove the dependency in zope.container on zope.filerepresentation. If an application is going to use zope.container.directory, it will need to import zope.filerepresentation.interfaces itself, and it will have the zope.filerepresentation dependency itself. I'd add deprecation warning in zope.container.directory. I wouldn't add these interfaces to zope.container.interfaces.
What about adding zope.filerepresentation as an extras_require "directory"?
I think extras are stupid, except possibly in the case of test extras and I think there are probably better ways to handle those.
If somebody is using zope.container.directory, it is possible to depend on zope.container [directory].
Sure, but if they want to *use* zope.container.directory, they have to separately import zope.filerepresentation.interfaces, in which case they're already depending on it, and a dependency in zope.container, even in an extra, is superfluous. but, whatever :) Jim -- Jim Fulton Zope Corporation
Hello, I just committed the removal of the dependency from zope.filerepresentation to zope.container, breaking the dependency cycle. * 2009-07-08 15:13, Jim Fulton wrote:
Sure, but if they want to *use* zope.container.directory, they have to separately import zope.filerepresentation.interfaces, in which case they're already depending on it, and a dependency in zope.container, even in an extra, is superfluous.
It seems the only user of zope.container.directory is zope.app.dav, but for this reason I'm not going to touch zope.container at all. All in all, remove the circular dependency was my original goal. :) Thanks. -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _____________________________________________________________________ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564
Fabio Tranchitella wrote:
Hello,
I just committed the removal of the dependency from zope.filerepresentation to zope.container, breaking the dependency cycle.
A belated yay! Thanks! Regards, Martijn
participants (4)
-
Fabio Tranchitella -
Jim Fulton -
Martijn Faassen -
Tres Seaver