Re: [Zope-dev] List of packages in the ZTK
Hey, Fabio Tranchitella wrote: [snip] I still think that starting from a very small list, allowing zope committers to add packages making an explicit commitment to maintain them would give us a better overview of what does ZTK mean for each of us. I'm of the opposite opinion; let's start with a moderately big list, more or less what was in Zope 3, but with anything ZMI related definitely planned for removal (and there's some other stuff). This is to recognize the reality that real apps right now depend on a *lot* of these packages. A lot of this code is not actually being used, which is why we do the refactoring, but I'd like to shrink gradually, instead of grow from a small core. This is because right now we'll have an easier time shrinking stuff down by fairly mechanical reasoning without involving a lot of people. A growing strategy that determines who is interested in maintaining a package sounds like it needs a lot of communication from a lot of people. In general it'd be good to avoid that.. (I can imagine however we could automate this partially by digging through SVN logs - that information might be interesting) 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] ZTK policy and package list (was Re: List of packages in the ZTK)
Fabio Tranchitella wrote: I've created a policy draft as well as an initial list of packages on a wiki page, which I hope will help us to collaborate on the list: http://wiki.zope.org/zope3/ZTK About the text on the wiki page: Addition of new packages A new package can be added to the ZTK in the following cases: * it has been factored out from existing ZTK packages; * it provides new fundamental blocks or features that change the way the toolkit-based libraries are used. I like this set of guidelines. In order to add the package to the ZTK, all criteria defined by the policy must be met. This line makes little sense to me. If I factor zope.foo out of zope.bar, I don't provide a new fundamental building block or feature that changes the way the libraries are used. zope.foo is still the in the ZTK. In case consensus can't be reached among Zope developers, the Zope Steering Group has a final word about the addition of the package. I'll happily reverse this, as the Zope Toolkit Steering Group by definition manages the Zope Toolkit. It always has the final word on the addition of a package, consensus or not. Of course another task of the steering group is to strive for consensus. I'd just say: The Zope Toolkit Steering Group decides whether a package can be added to the Zope Toolkit. We can defer to the other document we already have about steering group decision making: http://docs.zope.org/zopetoolkit/steeringgroup/decisionmaking.html Removal of packages A package can be removed from the ZTK if all the following conditions are true: I think 'all conditions' is too strict. the package provides features that are not needed anymore because: * other packages provide compatible features; compatible - comparable? * there are better alternatives. * no package in the ZTK depends on it. I have more difficulty with this, as I like to start with a more inclusive list. Therefore, I want to remove packages that contain functionality, such as the ZMI implementation, and things like 'code in the ZODB' support that was experimental. I think we can remove packages by the following *guidelines*: * no other package depends on it. * there are better alternatives. * the feature the package defines is deprecated. That's loose, as I don't define how features get deprecated. But that's fine, as we're humans and we can make sensible decisions in specific cases. I've put into the list the packages that I'd consider part of the ZTK and that I use in my applications. I don't know anything about grok and I doN't have a list of ZTK libraries used by zope2 or repoze. Okay, I really think we should end this discussion now; it's just not productive. I think the consensus within the steering group trends towards inclusion (where Stephan wants to include way more than the others). So, the list of packages in the ZTK was prepared by Christian Theune and is here: http://docs.zope.org/zopetoolkit/about/packages.html Any other list (such as the one on the wiki page you created) is not the ZTK list. In addition, we are maintaining the documentation on the ZTK here: http://svn.zope.org/zopetoolkit/trunk/ A wiki might serve as a scratchpad for proposals and I'm fine with that, but let's make sure that: * the wiki page marks itself as a proposal clearly, otherwise it's a decoy. It's not the real documentation. * we integrate any such accepted proposals in the official documentation Another way to propose documentation would be to create a branch of the zopetoolkit documentation in SVN. I'd like to ask help from everybody who cares about the ZTK to enhance the list adding the packages that they use, their zope.org username in the list of the developers for the package they are willing to maintain and the framework which are consumers of the libraries. I really think this is the wrong way to go about it. In order to produce your list you'll need *everybody* to pay attention and do something. I don't think such general cooperation of everybody is generally successful. IMHO, it is easier to get a real list if we start from an empty one and we add packages instead of starting from a huge list removing packages. -1, and I consider this a Zope Framework Steering Group decision. 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] KGS trunk without failures
Hey, Wolfgang Schnerring wrote: [snip] After we reach a consensus on how to do it (I'm in favor of the way outlined above, of course ;-), I'd like to add a step-by-step walkthrough of the day-to-day development of a package somewhere below http://docs.zope.org/zopetoolkit/process/index.html, which would include a description of how to run KGS tests. That'd be awesome! Regarding the KGS, I have a question: Where is the current KGS and how do we update it? For the Zope Toolkit, I don't think it exists yet. There's a Zope 3.4 KGS and I know Stephan also mentioned wanting to make a 'wide KGS' that includes a lot more packages than what's in the ZTK (this can expand on the ZTK KGS though). For Grok, we maintain a versions.cfg list in the Grok trunk. By where is I mean the location of the versions.cfg, by current I mean the trunk, the version currently in development, the version where we probably want to bump the version number of a package as soon as a version is released, and by update I mean that I'd like this operation to involve no manual interaction other than committing the new version number to SVN. I'd like to see such a method of working too. 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] KGS trunk without failures
Jim Fulton wrote: (Note that I'm using more precise jargon: project rather than package. In the Python world, the word package means a module that is implemented as a directory rather than a file. A project is a collection of software for which we create distributions. We should generally be using the word project rather than package.) +1 on the more precise jargon. 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] KGS trunk without failures
Hey, Wolfgang Schnerring wrote: * Fabio Tranchitella kob...@kobold.it [2009-08-07 11:46]: * 2009-08-07 11:42, Wolfgang Schnerring wrote: http://svn.zope.org/*checkout*/zope.release/trunk/releases/controlled-packages.cfg IMHO the KGS testing should be done using the controlled-packages.cfg and not versions, because some of the packages in the KGS are marked as not to be tested. If controlled-packages.cfg is to be the authoritative represenation of the KGS (and maybe it should be, since it contains more information than versions.cfg) then I'd probably wish for a buildout recipe that can pin versions based on that data format, because I much prefer less moving parts. In other words, I would very much like a single gesture to tell buildout use this KGS: extends=something-or-other.cfg. The rest should Just Work(tm). I'm +1 on this, the less moving parts the better and the less compiling/generation we can get away with, the better too. It needs to be as straightforward as we can make it. I do think we need a computer readable system that includes information like this: * whether a project is in a KGS (such as for the ZTK) * whether a project is used to test a KGS (a package not in the ZTK but used to test whether changes don't induce breakage, let's say, grokcore.component) * the locked down version of the package. * where the *next* version of the locked down version is being developed. Generally this is the SVN trunk, but could be a stable branch. The system that manages this shouldn't be tied to Zope in particular. It'd be great for managing, say, Grok's, KGS too. 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] Optional integration need not introduce dependencies
Hey Jim, [optional integration and dependencies] Would it be possible to turn this into a guideline document somehow that we can include in the Zope Toolkit documentation? 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] Simplifying dependencies of zope.app.publisher
Hey, Jim Fulton wrote: [snip] I do have some ideas for some specific minor cleanups in some of these. (That had to do with zope.app.publication, not zope.app.publisher.) That was blocked by the general instability we have right now. I'd really like us to stop moving things around until we get to a point where we have a reasonable kgs that has tests passing in Python 2.4-2.6 and on at least linux and mac. Once we have that and the processes in place to keep it, we can start to make progress again. +1 on this. That's not to say I regret the progress we did make in the past, but past time to consolidate again before we can take new steps. 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] SVN: zope.publisher/trunk/ Moved dependency on zope.testing from install_requires to tests_require.
Hey, Fabio Tranchitella wrote: [snip] In zope.component we use tests_require, in the very same way, for example. Shall I remove it there, too? Is there a policy/document which explains how we use extras and tests_require? Probably not. I think it'd be very good to add something like this to the Zope Toolkit documentation in SVN. Do you think you can write something? Please send it to the list so people can review it before we add it to SVN. I'm a bit hesitant to introduce a test extra if it is just for zope.testing, though. The complication introduced by the extra doesn't seem to outweigh the advantage of loosing that one package to me. To me it looks weird: tests_extra is there for this specific reason. Why shouldn't we use it? There are reasons which I forget that are discussed on this mailing list some time ago, quite extensively at the time... One of the things we want to do with the Zope Toolkit project is to document decisions so that the same stuff doesn't keep coming up. This is a good example. 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] KGS trunk without failures
Hey Fabio, Fabio Tranchitella wrote: * 2009-08-07 11:42, Wolfgang Schnerring wrote: [buildout] develop = . parts = whatever else you need compat extends = http://url/to/kgs/versions.cfg # assuming said versions.cfg uses a section called [versions]: versions = versions I've done something similar in z3c.recipe.kgs (which is a fork of compattest, I did not want to commit anything there, but I'm more than happy to bring back my changes). Ah, cool, I do hope we can merge your changes back again into z3c.recipe.compattest soon. Next time perhaps consider just branching in the SVN? That way it's clearer that changes can be merged back in.. 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] zope.app.module, zope.app.interface and zodb in KGS?
Hey, Jim Fulton wrote: [snip] Then the question is whether the dependence of zope.app.zcmlfiles on zope.app.interface is needed. I'll look to see what that's about. For the record, I'd be happy to see zope.app.interface and zope.app.module gone from our dependencies. zope.app.zcmlfiles too, but that's going to be a harder nut to crack, I expect. I'd really like to get to something more flexible that zope.app.testing.functional, to make it simpler for applications to use only as much set up as they need. zope.app.testing.function was great in its time, but I think we can do better. +1. It's keeping a lot of (testing) dependencies alive. In general it's nice if a package's testing dependencies are equivalent to its normal dependencies, i.e. (almost) no testing dependencies. 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] Some thoughts on KGS
Hey, Jim Fulton wrote: I think the KGS should define 3 categories of packages: - ZTK packages These are packages we maintain and expect people to build things on. - Test packages These are packages that build on the ZTK. These are used to test the ZTK packages, but aren't part of the ZTK. Could you give an example ofa 'test package'? I'm having trouble thinking of what these might be. - dependencies of ZTK packages or test packages. Note that the ZTK should probably avoid non-third-party dependencies that are not part of the ZTK. There are some fuzzy cases, like ZODB and ZConfig. What would 'dependencies of ZTK packages or test packages' be? Aren't those third party packages? I propose that any test infrastructure we come up with needs to handle these 3 cases. In any cases, the test infrastructure needs to fix version for all of the categories of packages and there needs to be a formal process (uh, like tests passing :) for updating the configuration. Could you say a bit more about what's motivating this proposal? 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] Breaking the dep cycle between zope.{container, filerepresentation}
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 ___ 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] Packages to be released
Hey, Fabio Tranchitella wrote: I'd like to release some packages with fixed/improved dependencies: - zope.location - zope.sendmail - zope.pagetemplate - zope.app.publisher - zope.filerepresentation These packages are already ok in the repository, but I don't have the rights to do the upload to pypi. Can somebody do the releases? Can I prepare the job in someway? Can I have release permissions for the packages? My pypi nickname is kobold. Belatedly I'm giving you pypi permissions. To Jim: We've been giving out permissions a lot to people who take the responsibility to work on packages, and I think the gained participation outweighs the breakage - we should be running a compatibility test regime if we care about complex inter-package breakages. 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] KGS trunk without failures
Hey, Stephan Richter wrote: - Insufficient dependency lists. I wish we were publishing z3c.recipe.depgraph results for all these packages in a convenient place. I'm worried that fixing dependencies introduced cycles again (that were of course really there). That's not to complain about all the work done to make sure tests pass at all, just to make sure we keep our dependencies free from cycles and as flat as possible. Thanks, 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] Why does zope.tales explicitly pin versions in buildout.cfg?
Shane Hathaway wrote: Fabio Tranchitella wrote: Is there a specific reason for having the version pinning? Automatic testing of zope.tales obviously fails using the KGS, because zope.traversing there is 3.7.1. Is it possible to remove the versions stanza? Sure. Pinned versions are OK for a maintenance branch, but not the trunk. +1, at least for most libraries. It can get messy not to pin if you depend on a lot of libraries, and frameworks do that. So Grok will continue pinning down versions in its trunk for the time being. :) 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] Simplifying dependencies of zope.app.publisher
Hey Fabio, Fabio Tranchitella wrote: I'm sorry if I am flooding the list with all my requests/messages, but I don't want to introduce changes without approval of more experienced zope developers. A belated +1 to discussing things, and +1 to doing work. :) I was analyzing zope.app.publisher, and I found that it would be possible to remove its dependency on zope.container because the latter is only used in zope/app/publisher/xmlrpc/configure.zcml to declare thee views like this: view for=zope.container.interfaces.IItemContainer type=zope.publisher.interfaces.xmlrpc.IXMLRPCRequest provides=zope.publisher.interfaces.xmlrpc.IXMLRPCPublisher factory=zope.container.traversal.ItemTraverser permission=zope.Public / I think these snippets should me moved to zope.container's configure.zcml, where we already have other traversers. Do you agree with this change? I remember looking at this relationship in the past but I don't remember noticing it was this easy. If this looks possible, by all means go ahead. 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] zope.index 3.5.2 broken
Hey, Andreas Jung wrote: [snip] The diff between 3.5.1 and 3.5.2 is pretty long and substantial. I doubt that such a major change us ok as a bugfix release. I should have become a new major release. From what you say, agreed. 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] Move implementation of getParent to zope.location?
Thomas Lotze wrote: There are two functions in zope.traversing.api, getParent and getParents, that are rather closely related. The former is implemented right in that module while the latter adapts its argument to zope.location.interfaces.ILocationInfo and calls getParents() on that. Why is getParent not a part of ILocationInfo? If there's no good reason, I'd propose adding getParent() to the interface and changing the getParent function in zope.traversing to work similarly to getParents, i.e. call a method on an ILocationInfo adapter. One question to ask is whether getParent and getParents are used all over the place or just by zope.traversing. If they're only used by zope.traversing we might not want to move them to a more general place, but perhaps we can even see about removing them. But really, +1 to moving these functions to zope.location. 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] Packages to be released
Hey, Jim Fulton wrote: Well, um, we're in a position now where the various packages we've released don't seem to work together, because we've been releasing individual packages without running combined tests. I know this isn't your fault, but I'm queezy about doing more of this. z3c.recipe.compattest is our friend. we should run it more often. Regadrs, 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] List of packages in the ZTK
Hey, Fabio Tranchitella wrote: it is evident that there is no consensus on the list of packages that are part of the Zope Toolkit. As Gary suggested me, it looks like the concept of ZTK is different for each developer and it is more or less the packages I use and I care about. In a way the consensus should be reflected by the list you mention: http://docs.zope.org/zopetoolkit/about/packages.html We need a policy to define the ZTK in an explicit way, otherwise we will never get a *real* ZTK KGS that can be used to build applications and the whole concept of ZTK will always be fuzzy. We have a list. I propose that in order to stop long discussions about what should be in this list, we just start with what's in this list, by circular definition. :) We need to get a procedure in place to do compat tests of what's in that list, dependency graph guarding of what's in that list, and locking down a KGS for that list. I think that since we have a list doing all these things is only a matter of work - there's no fundamental questions we need answered before we can do this work. Once the base is there we can expand on it. I think what we need is a policy for adding packages into this list, and retiring packages from the list. Removal: I think an informal show of hands that asks is this package important? on the mailing list is useful there. The other is a situation that nothing depends on that package anymore. Once those two are reached, I think it'd be as simple as petitioning the steering group to have a package removed. Addition: this one is much tougher. New packages can get added if they're factored out of existing packages, that's easy. But fundamentally new package? We need to cross that bridge when we get to this. I suspect innovation for the time being will mostly be around the toolkit, not in it, or in the form of changes to existing packages. I think generally candidates for addition are packages that would change the way we arrange toolkit-based libraries themselves - I recall Shane's WSGI discussions as an example. I realize that to build real apps everybody will come up with a list of extra packages beyond the ZTK that they feel are needed too. Let a thousand flowers bloom I'd say - we just need a clean, fertile soil that we need to maintain. We already got plants growing in the soil anyway (Zope 2, Grok, bfg, and lots of Zope 3 apps). And of course there's some philosophy behind what's in the list now: it's a set of libraries shared by Zope 2, Zope 3 (whatever that is) and Grok. That's not the only answer and it's not quite the correct answer even, but philosophers spend way more time trying to pin down far more important concepts than the nature of the ZTK. Reality, mind, knowledge, good and evil are some examples. They haven't agreed yet either and they've had thousands of years to argue. In reality we still find those concepts useful. So let it be with the ZTK. 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] A couple of questions about (maybe) missing dependencies
Hi there, Fabio Tranchitella wrote: While analyzing the dependency graph of one of our applications, I found some missing dependencies. I'm not sure these are bugs, but I'd like to ask your opinion about them: - zope.app.publisher does not depend anymore on zope.app.pagetemplate, but it uses it in src/zope/app/publisher/browser/viewmeta.py zope.app.pagetemplate.simpleviewclass import SimpleViewClass Seems like a bug at first glance. Feel free to add the dependency back (though I hope we can look into removing it again). - shouldn't zope.pagetemplate depend on zope.security [untrustedpython]? it imports it in engine.py: from zope.security.untrustedpython import rcompile The same as above, seems like a bug, feel free to add the dependency back, better yet if we can devise a way to really get rid of it. - I think we should release zope.location (added miss dependency on zope.deferredimport, it is ok in trunk but not yet released); +1 - I think we should release zope.sendmail (not it depends on transaction instead of ZODB3, it is ok in trunk but not yet released). +1 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] RFC: ZTK custom publications, zope.app.publication, and zope.traversing
Jim Fulton wrote: [snip[ I made it possible to override proxying by overriding the proxy method. At this point, I think zope.app.publication provides a pretty reasonable base class for custom publication implementations, although the module arrangement could be made a bit simpler. Cool. :) I propose the following: In phase 1 reduce the scope of zope.traversing: - Move path traversal code to zope.tales I'm very much +1 for anything that moves ZPT-only traversal to places where it's less likely to confuse the reader of the code into thinking it's URL traversal. - Move the URL traversal code used by zope.app.publisher.menu to zope.app.publisher.menu. Refactor it to use the request.publication. Deprecate definition of menu items without permissions. I'm worried about how this affects dependencies. I wouldn't want, say, zope.container, zope.app.pagetemplate and zope.site to start depending on zope.app.publisher where now they depend only on zope.traversing (which is much more lightweight in the dependency department). If you can do this without making zope.container depend (indirectly) on zope.app.pagetemplate and the like, or, say, zope.site on zope.contenttype, then I'm +1. This means that we shouldn't make zope.traversing depend on zope.app.publisher at any stage, as this would completely screw up all graphs. The dependency for backwards compatibility should ideally be a loose one, not marked in the setup.py dependencies and only required if backwards compatibility is needed. Thoughts? Please do watch those dependencies... The z3c.recipe.depgraph buildout recipe can help you generate dependency graphs. Please watch the scc graphs to see whether you aren't inadvertently creating more cycles. 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] refactoring site functionality
Chris McDonough wrote: On 6/4/09 11:59 AM, Martijn Faassen wrote: [snip] I don't think it's complicated. It's nice to install an object somewhere that stores data and has a UI and also be able to register it as a local utility. If you were to have mutable global configuration, you'd need some way to expose it to the UI and content-space too. This is true. OTOH, I've never really been keen on the idea that the CA API should be bent around the idea that you're going to often want to find a persistent registry. It seems just as reasonable to: - put a persistent object someplace (with its own UI) that isn't registered as a CA utility. - find it via the location API when you need it in your code. By location API, you mean something like mycurrentapp()['foo']['bar']? - *Pass* it to global utilities (or adapters) when you need to vary behavior based on location. Doesn't this make you have to scatter a lot of location-getting and context-passing code throughout your codebase? I guess it depends on how your codebase is factored. But say you have a utility that sends email, and can be configured with the email address to send it to somewhere in a config screen, you could have 10 places in your code that need to get the configured email address and then pass it to the utility. Now that's probably easy enough to encapsulate in a function, but: * but if you have your configuration right there in the local utility it comes pre-encapsulated. Now you got two bits, one that knows how to send email and one that is being configured. This separation into bits may be right in some cases, but it seems overkill in many. * you're going to have to pass your current application context in each time you want to send email. That's avoided with a utility lookup (as this is implicit). So, I'm having trouble seeing the benefits to this alternative approach, could you explain? 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] refactoring site functionality
Wichert Akkerman wrote: Previously Martijn Faassen wrote: * often it is nice to have application configuration to have a user interface, so that end users can configure aspects of the application. This may be filling in an email address or customizing a template or adding a user, etc. Local utilities are a nice solution for this, even if there is just a single application installed. That sounds like a complicated workaround for not having a mutable global configuration. I don't think it's complicated. It's nice to install an object somewhere that stores data and has a UI and also be able to register it as a local utility. If you were to have mutable global configuration, you'd need some way to expose it to the UI and content-space too. 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] refactoring site functionality
Hi there, Jim Fulton wrote: [snip] I think we're talking about 2 different things. There is the registry that is local to the root object and that is stored in the database. Having registration data in the database makes sense for a number of reasons and I don't consider this advanced. This is effectively a global registry. It doesn't really matter that it is attached to the root folder. Then there are registries sprinkled around the object tree below the root. These are truly local, because they pertain to a subset of the object tree. This is the usage that I think we should relegate to an advanced feature and rethink the goals for. Most importantly, IMO, we should avoid having this advanced usage complicate the lives of 98% of developers who don't need it. So if I understand you correctly, when you say 'root' you're talking about the ZODB root, not a particular application's root? And you're suggesting there be only a single db-dependent registry in the ZODB as the basic use case, and that people can register object in the ZODB into that registry? I'm not sure how this simplifies matters very much compared to the current API, which isn't all that complicated in my experience. The one thing I can see is that 'setSite' and traversal hooks could potentially go away. Is that what you're thinking about? 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] refactoring site functionality
Christian Theune wrote: [snip] I find this pattern to be pretty neutral WRT the web or to locations (as we know them from zope.location). I think you're describing the pattern of (contextual) acquisition? :) Unfortunately, I do have to point to a naming thing: the component lookup methods already support an argument to say where to look for registries: it's called 'context'. Yes, that's a good point. 'context' is a rather broad term though, perhaps 'acquisition context' would work. :) 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] [Checkins] SVN: zope.app.http/trunk/ - Replacedthedependency on zope.deprecation with BBB imports
Hi there, Roger Ineichen wrote: [snip] The only thing I could say about this concept is that we didn't start to remove #BBB marked imports. Just wait till we start remove the BBB imports and the packages from install_requires ... Since we were hardly in a hurry removing deprecation warnings *years* after we promised to remove them in the text (there's still some around), I can't say we'll be in that much of a hurry to remove these. :) 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] [Checkins] SVN: zope.app.http/trunk/- Replacedthedependency on zope.deprecation with BBB imports
Hey, Stephan Richter wrote: [snip] I have been following this discussion and just want to mention that I fully agree with Roger. If you release a final version of Zope or a package that spews deprecation warnings or has not fixed the imports, then this should be considered bad releasing. I'm not sure I understand this. If you are releasing a final version of zope.app.component, do you want it *not* to spew deprecation warnings? Or do you mean you require someone to go through all packages that may depend on zope.app.component and change the imports there before zope.app.component is released? But if so, you'd need to release zope.app.component with deprecation warnings. Several times in the previous discussion I heard people talk about wanting to support multiple releases of a single package and not wanting indirect deprecation warninsg. I'm not going to defend their view here myself, but I must note we've been spending some months now moving away from zope.deprecation. I highly doubt that this will hurt us seriously in the coming years. And if it does, at least we'll be using Python imports amenable by analysis by any Python programmer, with records in the CHANGES.txt that can be read by anyone, and not our own home-grown import system using module proxies. 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 )
[Zope-dev] RFC: Site - Locus
Hi there, We have a concept of Site in the Zope Toolkit, along with SiteManager and the like. What this concept allows us to do is locally register components. Most typically this is used for local utilities such as a catalog. During traversal, a thread-local is set with the current site, so that code that looks up a compoment will check the current site(s) before falling back on the global component registry. The word site has bothered myself and others for some time. It doesn't really have the right connotations for random programmers; when you hear site you think about website, and that's not really what this implies. The reason we called it site I think has to do with the idea that we expected Zope-based web sites to be applications with a lot of local components. I'm interested in refactoring zope.site to split it into two packages: one that has the pure site-based logic with minimal dependencies, and support to easily test with sites, and the other with dependencies on zope.container. While thinking about this, I figured this might be a good opportunity to rename the word 'site' to something better. I propose we use the word 'Locus' instead of 'Site'. This word doesn't have a lot of connotations in the web programming world, and people can guess by simply looking at the word it might have something to do with *local* components. It's also short. It's also a synonym of the word site. The dictionary says: a place, a locality and the scene of any event or action. I think that works quite well. Two possible options for moving forward with this: * create a zope.locus package that contains the core locus support. It only speaks in terms of locus and doesn't use the word site * zope.locuscontainer will have the container support surrounding sites. * zope.site becomes a backwards compatible but deprecated package that does 'from .. import .. as' to keep 'getSite' and 'setSite' and such around. The package itself will be deprecated and people will be encouraged to depend on zope.locus (or zope.locuscontainer, but that will be rare). The other plan: * we fold the locus support into zope.component. This is assuming that the dependencies for Locus can be kept to a bare minimum (no ZODB dependencies either). * we add the LocusContainer support to zope.container directly; since it already uses zope.component this isn't a problem * zope.site is still a backwards compatible package (that depends on zope.container and zope.component, which it already does). The second plan is my favorite if it is possible dependency-wise and zope.component doesn't take on new dependencies. I think support for local components could very well be part of zope.component conceptually. It would allow us to eliminate one package (zope.site) without introducing any new packages (the other plan increases the amount of packages by one, trading zope.site for zope.locuscontainer). What do people think about: * the idea of renaming Site to Locus * the plan for refactoring? 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] RFC: Site - Locus
Hey, Jens Vagelpohl wrote: On May 28, 2009, at 13:08 , Martijn Faassen wrote: What do people think about: * the idea of renaming Site to Locus I think that's a terrible name. While site at least means something to people, locus doesn't carry any meaning in the specific knowledge domain you're trying to push it into. But the whole point is that while site means something to people, it gives people the *wrong* idea about what the functionality is actually about. A site in Zope terminology is something where local components can be registered and found. A site in any other web terminology means web site. site having a meaning to people already is actually a bad thing. If they see the word 'locus' they get two possible clues: * this is something I don't understand yet, so I need to figure it out. * Hm, I wonder whether it has something to do with local utilities. P.S.: Lokus is a slang word for toilet in German. Great connotation. My utilities need to go into the dump. Yes, many words we can use are bad slang word in some other language. Locus is also commonly used in genetics, my genes in the dump. :) We just need to watch out for slang words in English. 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] RFC: Site - Locus
Matthew Wilkes wrote: On 28 May 2009, at 12:39, Martijn Faassen wrote: * Hm, I wonder whether it has something to do with local utilities. I don't think I'd make this jump. I'd not be averse to a longer package name if it made it more explicit. I wasn't primarily talking about a package name, but about the name for the concept (which can then be reflected class names, and a package name, if such a package is necessary). 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] RFC: Site - Locus
Wichert Akkerman wrote: Previously Martijn Faassen wrote: I propose we use the word 'Locus' instead of 'Site'. This word doesn't have a lot of connotations in the web programming world, and people can guess by simply looking at the word it might have something to do with *local* components. It's also short. I don't see short as a very important quality here. It is not a name you have to type in often, so I would prefer something more descriptive. How about componentroot or componentcontainer.. I do find short an important quality here, because I find myself typing getSite() frequently, and in tests, setSite as well. It's also something one talks about. A site isn't a container, I'll note. A site is something that has local components registered but doesn't need to be implemented as a container at all. 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] [Checkins] SVN: zope.app.http/trunk/- Replacedthedependency on zope.deprecation with BBB imports
Hey, Roger Ineichen wrote: [snip] My fear is that deprecated imports will pull in packages and act as the single point of an egg declaration. If someone removes a dependency during a deprecation import cleanup lets say zope.formlib in z3c.form from version 1.9.0 to 2.0.0 then it's possible that a custom project didn't fix the zope.formlib depndency in his setup.py because there is no need to do so. I'm not sure I understand, but if you directly use zope.formlib you should have a direct dependency on it in your setup.py. Good luck if the last egg cleans up the zope.formlib dependency and you didn't fix it in your project for your self. This will end in loosing the dependency at all and you don't know why. Of corse you can fix this lost dependency and add it to your setup.py. But you still don't know why. You also can't find information about why in the zope.formlib package is not needed anymore because another package is responsible for not using the zope.formlib package. If you don't use zope.formlib, there isn't a problem. If you do use it, you should declare it. I'm not sure I understand the problem here. Of course the dependency refactoring will cause breakages here and there, but I don't think they're intractable (especially if we do provide a KGS for the toolkit packages). The deprecation message is a very important information and can keep you informed on what's going on and about new better concepts. I think you should be reading the CHANGES.txt of the packages you depend on when you upgrade the dependency. If you *don't* depend on a package directly, you normally shouldn't have to be concerned when it disappears. Of course there might be bugs introduced in this process: packages you do somehow indirectly depend on disappear. That's something we'll have to live with if we want to move forward at all. I don't see how zope.deprecation is going to make any difference in this in any way however - you won't see any deprecation warnings either as the underlying package is simply gone. A CHANGES.txt can contain much much better information than the deprecation warnings ever could. It can detail what happened, why it did, and what you should be doing. I've been rather confused with a what now? feeling when confronted with deprecation warnings in the past, and there was nothing else but these messages that I could investigate. 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] RFC: Site - Locus
Hey, Roger Ineichen wrote: [snip] What do people think about: * the idea of renaming Site to Locus Oh my god, many -1 Motivations beyond oh my god? One reason Locus might be a bad word is because it's easily confused with Location, a concept we already have. What I like to see is that we remove the default Folder container and simplify the hole implementation. I'm proposing we separate the folder implementation from the basic site functionality. It will then become easier for people to ignore the folder implementation and not use it, while we retain backwards compatibility for those who do need it. [snip] I think a dependency cleanup and split the same old bad concept into different packages is not usefull right now. What is the same old bad concept? Details? Are you aware of all the overhead we have in zope.site right now? Since I actually assembled these things into zope.site, I have some awareness of what is in there. Could you actually point to specific points in the zope.site code? It's not a lot of code, after all. I'm proposing we move some of this code into zope.component, and the rest into zope.container (or we could leave it in zope.site for now). Where is the overhead we can safely remove? 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] RFC: Site - Locus
Roger Ineichen wrote: [snip] The site offers a SiteManagementFolder, SiteManagerContainer and a LocalSiteManager. The SiteManagementFolder by default installed as ['default'] is absolutly useless and obsolate since the last refactoring. It's just a container, earlier it was a kind of namespace. Yes, with Grok we've been installing directly in the SiteManagementContainer (which contains the folder, if I got my terminology right). We can't just get rid of this though, as it would break a lot of existing ZODBs. [snip] Just refactoring zope.site and move the same packages arround because of dependencies is in my point of view the wrong thing. We need to define wich package will offer which parts of the hole site concept. otherwise it could be useless if at the end all packages get used together in 99% of all Zope projects. Of course if we make such a separation each end needs to be useful for something. What do you like to use independently from each other which is now assembled as a unit in zope.site? One use case I have is that I want to be able to write tests that just deal with site management without pulling in a lot. I have done this with hacked up code now in both z3c.saconfig and hurry.custom. The other use case I have is that I want to write packages that just need to be able to set the site or get the site and shouldn't need to care about, or depend on, zope.container at all. 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] RFC: Site - Locus
Fabio Tranchitella wrote: * 2009-05-28 13:09, Martijn Faassen wrote: What do people think about: * the idea of renaming Site to Locus What is the technical advantage of renaming Site to Locus? To me it looks just like a (not so necessary) cosmetic change. Obviously there is no technical advantage to a renaming. But good naming is important. I'm fine if people don't like Locus, but I do think Site has been misleading, so it'd be nice if we could come up with a better word. Alternatively I'll just stick with 'site' and shuffle the code around without renaming. 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 )
[Zope-dev] refactoring site functionality
Hey, Jim Fulton wrote: 2. I think local configuration address use cases that most people don't have but introduce complexity that I bet a lot of developers trip over. I think there are two cases where people typically deal with local configuration: * setting up local utilities (for authentication, the catalog, application-specific configuration storage + UI) * writing tests that involve local utilities. (a more advanced case, but still quite common) 3. I think the right word here is local registry. I think the whole concept should be labeled as advanced and we should discourage people from even pondering it unless they have a strong use case, like wanting to host multiple web sites with different configs in the same application. :) I don't think hosting multiple web sites with different configs in the same application is the only use case. * the catalog. This can be done using a global component that somehow stuffs information in the ZODB, but there are no common patterns for this that people can follow, so local utilities are currently easier to use. * often it is nice to have application configuration to have a user interface, so that end users can configure aspects of the application. This may be filling in an email address or customizing a template or adding a user, etc. Local utilities are a nice solution for this, even if there is just a single application installed. 4. I think we should step back (re)think how we handle the goals that drive this. If we do, we might come up with something so different that we'd make this discussion moot. My goals are: * I do care about local component configuration * I'm a simple person and want to make my life easier * I want to be able to write and test local utilities without having to depend on zope.site for my testing (right now I have a hacked up version that I just copy and paste). An example of the hacked up version of site management is here: http://svn.zope.org/hurry.custom/trunk/src/hurry/custom/testing.py?rev=99648view=auto And I'd like to put that code somewhere proper. * I'd like to change the dependency structure so that a minor dependency on site management doesn't require a package to pull in zope.container (which pulls in quite a bit itself) Regards, Martijn P.S. As of this point I'm dropping my proposal to rename anything to anything. Let's indeed focus on the wider discussion (as indicated by Roger and Jim) ___ 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] RFC: Site - Locus
Hey, Roger Ineichen wrote: [snip] Probably a rare use case or could become imporant if we use other patterns then the container traversal pattern. Do you have some ideas of using a contianer less traversal pattern? Take a look at this graph: http://startifact.com/depgraphs/zope.app.publisher-after2.svg zope.app.publisher is pointing at both zope.container and zope.site. I believe it's possible to break the dependency on zope.container. But if we did so and still had a (small) dependency on zope.site, we won't gain anything. If we do manage to break both dependencies, we can lose zope.site, zope.container, zope.cachedescriptors, zope.dottedname, zope.broken and zope.filerepresentation and zope.lifecycleevent from its dependency graph, if I read it well. That's 7 packages. :) 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] [Checkins] SVN: zope.app.http/trunk/ - Replacedthedependency on zope.deprecation with BBB imports
Hi there, Before we have this discussion yet again, I will record the official stance in the zope toolkit decisions document, and I'll quote it here: * When code moves to a new location to import it from (in the same or another package), use a ``from foo import bar`` statement, with a ``#BBB`` comment to indicate the import is only there to support backwards compatibility. In the CHANGES.txt of a package, state that an import location got deprecated and where the new location is (making this a feature release, not a bugfix release). Reasons: * it avoid a dependency on zope.deprecation, which is quite involved in its implementation, using proxies. * A ``from .. import ..`` is immediately comprehensible to any Python programmer as well as tools. * Deprecation warnings make it hard to write a library that supports multiple versions of another library; a change in an indirect dependency can create deprecation warnings that the original developer does not care about. * We are in the process of developing a testrunner extension that will report on indirect imports, and a ZODB upgrade procedure. Feel free to discuss it, either to add arguments to refine this, or to attempt to overthrow this decision entirely. 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] [Checkins] SVN: zope.app.http/trunk/ - Replaced the dependency on zope.deprecation with BBB imports
Stephan Richter wrote: On Monday 25 May 2009, Shane Hathaway wrote: +- Replaced the dependency on zope.deprecation with BBB imports As a general question, how will people know that an import location changed? CHANGES.txt. Christian Theune wrote a test runner extension a few months ago that can tell people there is a more direct import available. It still hasn't been released, though... Christian also wrote a tool (status unclear too) that can update an existing ZODB in the case of persistent objects. 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] [Checkins] SVN: zope.app.http/trunk/ - Replaced the dependency on zope.deprecation with BBB imports
Hi there, Roger Ineichen wrote: Sound interesting, what's an indirect imports checker script? Code that Christian Theune should fold into zope.testing as soon as possible. :) 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 )
[Zope-dev] zope.testrunner import location notifications
Hi there, (in particular Christian Theune) What's the status of the 'import location' notification functionality in zope.testrunner? What's the status of the ZODB migration code? 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] package dependency refactoring progress report
Shane Hathaway wrote: Martijn Faassen wrote: I'm not sure about zope.rest; there's already a z3c.rest which likely does something quite different, and I think a zope.rest package should actually *talk* about REST. What about zope.httpview instead? Well, no, I don't think it's generic enough to call that. zope.app.http is almost a webdav implementation, except I'm not sure it implements enough to actually work with most webdav clients. Maybe we'll leave this behind in zope.app.* space for the moment and focus on the others, then? Another note, I think we should consider splitting off zope.app.publisher.xmlrpc, which looks quite independent from the rest, into its own package. So: zope.app.publisher - zope.view, zope.xmlrpcview I've pondered this split before, but AFAICT it would only increase the number of dependencies, so I've been waiting for the graph to shrink before talking about it. It would allow a whole chunk of code to be cut out for those people who don't care about XMLRPC or don't even want to enable it on their server. The reason I bring it up now is because this split would be best done while we are moving things out of zope.app.publisher anyway. If we did it afterwards, we'd need a backwards compatibility dependency from zope.view on zope.xmlrpcview. 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] package dependency refactoring progress report
Shane Hathaway wrote: Martijn Faassen wrote: It's interesting to see zope.deprecation is a new dependency. We could consider changing these deprecations to simple imports if this is possible... Certainly, but what is the right way to deprecate code, then? We've just started to do imports instead, with a BBB comment. The idea is that tools exist (or almost-exist) that can report on indirect imports; the test runner has such an extension, though I believe it's still sitting on a branch. The idea is also that plain imports are better understood by random Python programmers. Knowing there are no cycles besides the zope.container one, this graph starts to look comprehensible, that's good. :) It's still really big though. Hmph. Yes. I think zope.container and zope.site are interesting candidates to look at removing as dependencies. I saw one dependency on getSite in zope.app.publisher (the rest are test dependencies)... I wish we could separate zope.site into two packages somehow. One would just contain the interfaces describing how to get to a site, and a way to easily *test* with sites, a testing module (I have some code sitting around that could help there). The other would actually implement a site in relation to containers. This work might be a good opportunity as well to think about renaming the word site to something else, as site isn't that great a word for a local component registry. The only direct dependency on zope.container (not through zope.site) is in zope.app.publisher.xmlrpc, in ZCML (see other discussion about zope.xmlrpcview, another reason to split this off :). The dependency of zope.app.pagetemplate on zope.dublincore is also relatively weak. 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] How to include a style media=print.... CSS file?
Hey, Hermann Himmelbauer wrote: [snip] 1) Simply write this directly into my page template 2) Hack zc.resourcelibrary, e.g. add a ZCML-directive media 3) Use some other package I'm unaware of hurry.resource (an improved take on zc.resourcelibrary's idea) can't do this right now either, but I suspect it's more hackable than zc.resourcelibrary. Let me know if you want to hack on it. 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] RFC: zope.app.pagetemplate.engine dependencies
Tres Seaver wrote: Resolution #1 = +1 Resolution #2 = Whereas: [removing evaluateInlineCode] zope.app.catalog: old-fashioned HTTP log test. Not very important. zope.app.publication: the same zope.app.exception: the same zope.app.session: actually turns on evaluateInlineCode in test setup for some reason. A discussion topic. zope.app.zptpage: actual code and tests that mess around with evaluateInlineCode. A discussion topic zope.app.session seems to be almost wholly moved to zope.session, leaving some ZMI stuff behind. I think this means we can safely ignore zope.app.session. zope.app.zptpage is the most interesting. It maintains an evaluateInlineCode attribute and passes it along to zope.app.pagetemplate. Of course it also is there to support the ZMI. Since it's unlikely anyone actually has *useful* ZPT pages with inline code, as nobody is programming with the ZMI anyway, I propose we just rip this support out of here. But this can be done later when we see things break. +1 for removing it. Resolution #3 = I'm fine with this, though haven't done any real analysis. :) 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] package dependency refactoring progress report
Hey, Shane Hathaway wrote: Done. I look forward to seeing the changes in the dependency graph. Great, thanks! The only cycle left in the zope.app.publisher graph is between zope.container and zope.filerepresentation. The graph now contains 42 notes, so we got rid of 3 more dependencies. Here it is: http://startifact.com/depgraphs/zope.app.publisher-after2.svg It's interesting to see zope.deprecation is a new dependency. We could consider changing these deprecations to simple imports if this is possible... Knowing there are no cycles besides the zope.container one, this graph starts to look comprehensible, that's good. :) Here's zope.app.publication (same zope.container cycle, no other cycles); http://startifact.com/depgraphs/zope.app.publication.svg And here's zope.app.http: http://startifact.com/depgraphs/zope.app.http.svg (again the zope.container cycle, nothing else) 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] package dependency refactoring progress report
Hi there, Shane Hathaway wrote: [snip] Summarizing: zope.app.publisher - zope.view zope.app.publication - zope.publicationregistry zope.app.http - zope.rest I'm not sure about zope.rest; there's already a z3c.rest which likely does something quite different, and I think a zope.rest package should actually *talk* about REST. What about zope.httpview instead? Another note, I think we should consider splitting off zope.app.publisher.xmlrpc, which looks quite independent from the rest, into its own package. So: zope.app.publisher - zope.view, zope.xmlrpcview One question is whether zope.httpview and zope.xmlrpcview are really similar enough to warrant such a similar naming convention. zope.app.publisher.xmlrpc does not only define some XMLRPC-related views, it also defines a ZCML directive, which zope.httpview doesn't do. I also wonder what should happen with zope.publisher.xmlrpc (which also looks quite independent from the rest of the zope.publisher code). 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] package dependency refactoring progress report
Shane Hathaway wrote: Martijn Faassen wrote: So, the only dependency cycles left in zope.app.publisher are these: zope.app.publisher -- zope.app.publication -- zope.app.http I fixed those tonight. On the trunk, there are no longer any dependencies between zope.app.publisher, zope.app.publication, and zope.app.http, except testing dependencies. Cool! Thanks very much! Here is a summary of what I did: [snip summary] - I used zope.deferred to deprecate things I moved from zope.app.publication, zope.app.publisher, and zope.app.http. Are there any objections to using zope.deferred in those packages? No objection, but what's the reason to use zope.deferred instead of straight imports or zope.deprecation? To break the dependencies? In all, I changed 6 packages. Should I release them now, or should I look for other dependencies we might clean up at the same time? I'm +1 on releasing now. (and thanks for making them feature releases) Getting these things out there gives everybody who plays with this nicer dependency graphs and this tends to help improvement. 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] package dependency refactoring progress report
Hey Shane, Shane Hathaway wrote: Shane Hathaway wrote: Martijn Faassen wrote: So, the only dependency cycles left in zope.app.publisher are these: zope.app.publisher -- zope.app.publication -- zope.app.http I fixed those tonight. On the trunk, there are no longer any dependencies between zope.app.publisher, zope.app.publication, and zope.app.http, except testing dependencies. I should take a moment to describe the different purposes of these packages as I see them now. Conceptually, they are really quite independent. Thanks for doing this analysis, and considering improved naming. I think good naming is very important, and it will help get this functionality out of the 'zope.app' ghetto. - zope.app.publisher: A library of ZCML directives for configuring views. Also provides generic view classes. A better name for this package might be zope.basicviews. A lot of packages depend on this. I'm not sure 'basic' needs to be in there. Do we have anything less basic? What about simply calling it zope.view? (I don't like the plural in package names either generally) - zope.app.publication: Provides IPublication implementations and a mechanism/registry for choosing a different publication class for each request. Most packages should not depend on this. A better name might be zope.publicationregistry. I'm fine with this. I was considering 'zope.publication', but we already have 'zope.publisher' so that'd get very confusing again, something we should avoid. - zope.app.http: Provides generic views that translate HTTP verbs like PUT, DELETE, and OPTIONS into map operations. The idea is clever, but not everyone needs a REST-style API. A better name might be zope.httpverbs. Even though I don't really like the plural, I think 'zope.http' would promise a bit too much, so 'zope.httpverbs' sound better. So if we get some consensus about this, we need volunteers that can help move the code over to these new packages and leave backwards compatible imports in the old places. Is there anything in these packages we can safely leave behind do you think? (ZMI related, perhaps?) 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] zope.app.component 3.8.2 release
Alexander J Smith wrote: I released a new version of zope.app.component to fix a bug introduced in the recently deprecation of its metadirectives. Packages that were broken by this should use this new version. Oops: sorry for the breakage and thanks very much for the fix! 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] zope.app.publication dependencies (volunteers needed!)
Hey, Chris McDonough wrote: [snip] I tried to go after this today (reversing the dependency setup between zope.formlib and zope.app.form). There are hundreds of changes that need to be made to move interfaces to zope.formlib. I made them (more or less mechanically) but then couldn't get the tests to pass. Since I don't actually use zope.formlib, I don't think it's appropriate that I commit anything. All right, thanks for trying. Hopefully someone else can take a look at it at some point. OTOH, I'm pretty convinced that this action would be a win for packages that depend on formlib. I found these: ./zope.app.component-3.7.0-py2.5.egg/EGG-INFO/requires.txt:zope.formlib ./zope.app.exception-3.5.0-py2.5.egg/EGG-INFO/requires.txt:zope.formlib ./zope.app.zcmlfiles-3.5.3-py2.5.egg/EGG-INFO/requires.txt:zope.formlib With the recent changes zope.app.component is almost devoid of code and packages that relied on zope.app.component now can rely on other packages and entirely avoid the zope.formlib dependency. zope.app.exception only depended on formlib's namedtemplate facility which now resides in zope.app.pagetemplate instead. zope.app.zcmlfiles is a scary package that just pulls in a lot of ZCML that hopefully can vanish entirely over time. 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] zope.app.publisher 3.7.0 release
Hey, Alexander J Smith wrote: I just released a new version of zope.app.publisher. The changes in this version are largely related to reducing dependencies on zope.app.component and zope.app.container. Thanks very much for doing this work! I could actually remove the (direct) test-dependency on zope.app.component from it as well, though the tests will still obtain it indirectly. 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 )
[Zope-dev] package dependency refactoring progress report
Hi there, This is a progress report on the package dependency refactoring work. We've had a lot of people contribute to this process (thanks everybody!), and bit by bit we are able to make a serious impact on dependencies. Yay! Let's take for example zope.app.publisher, which a few weeks ago had a dependency structure like this: http://startifact.com/depgraphs/zope.app.publisher-before.svg (60 dependencies, including zope.app.form and zope.formlib). After a lot of work on a lot of packages, we now have a dependency structure like this: http://startifact.com/depgraphs/zope.app.publisher-after.svg (45 dependencies, no more form related stuff) Still a big graph, but a lot simpler nonetheless, and down 15 packages. So, due to the recent changes we've now managed to cut away zope.app.form and zope.formlib entirely from zope.app.publisher's dependency chain (except for the tests). The main dependency cycles we started out with in the big graph were these: http://startifact.com/depgraphs/zope_app_publisher_cycles.svg After some work we'd gotten it down to this: http://startifact.com/depgraphs/zope_app_publisher_cycles2.svg And by now the main cycles left are these: http://startifact.com/depgraphs/zope_app_publisher_cycles3.svg So, the only dependency cycles left in zope.app.publisher are these: zope.app.publisher -- zope.app.publication -- zope.app.http And also this (familiar) one: zope.container -- zope.filerepresentation I need to do some more analysis to see what other complexities we have in the dependency chain in the ZTK. One obvious set of tasks is to continue evaluating dependencies of things like zope.app.publisher to see whether we cannot take out a few more. Just study the graph and see what can be done by examining the code: http://startifact.com/depgraphs/zope.app.publisher-after.svg For instance, what is zope.app.pagetemplate doing depending on zope.dublincore? What about its direct dependency on zope.container? Another set of tasks is to examine all the test dependencies we have, as those are way more complicated than the main dependencies. Ideally our test dependencies shrink to nothing as well. This will be a hard slog as we rewrite tests, but we can target one dependency at the time, too. 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] Availability of windows binaries for zope.container on Python 2.5
Uli Fouquet wrote: Martijn Faassen wrote: Alec Munro wrote: I was just reading that, and am now hunting around on which files exactly I have to modify to pin down the version to 3.8.1. Add a [versions] section to your buildout.cfg: [versions] grokcore.view = 3.8.1 This will pull in a fixed grokcore.view that won't pull in zope.container anymore. I am sure you meant:: [versions] grokcore.view = 1.7 Right? You're right, I wasn't thinking straight. :) 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 )
[Zope-dev] zope.app.component is now deprecated
Hi there, I've factored more bits out of zope.app.component; the last bits could go into zope.component. zope.app.component is now deprecated. I've made new releases of zope.app.component and zope.app.interface, along with zope.component. If a package depends on zope.app.component, try to fix the dependencies to point to the underlying packages. These are: zope.component [zcml] (zope:view, zope:resource directives) zope.security (various require directives) zope.componentvocabulary (component vocabularies) zope.site (site folder functionality) You can study zope.app.component's BBB code to see what needs to be modified. Hopefully this will allow us to untangle the overall import dependency story some more soon. 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] zope.app.publication dependencies (volunteersneeded!)
Shane Hathaway wrote: Martijn Faassen wrote: It might actually be the best to move these ZCML directives *down* into zope.component. That won't affect the dependencies of zope.component at all in fact; the [zcml] dependencies of zope.component already need all the dependencies that zope.app.component's view and resource directives implement. I see that zope.component now relies fairly heavily on the setuptools extras_require, which makes the proposed move possible. At what point did we decide extras_require is good? Just curious. We didn't. This extras_requires has been in there for a long time, as the other ZCML statements are already defined in it. In the past I proposed pulling out the ZCML statement implementations from zope.component into something like zope.componentzcml, or zcml.component or whatnot. That could still happen, if we can find some consensus. 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] Availability of windows binaries for zope.container on Python 2.5
Hi there, Alec Munro wrote: Just trying to install Grok, and as seems to be the tradition, some package updates have resulted in requiring a Visual Studio compiler to be installed. In this case, it seems to be zope.container 3.8.2. Is there a possibility of making a binary for this available? Relying on zope.container at this point in time is a bug in Grok, and we accidentally released it. See the recent discussion on grok-dev. 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] Availability of windows binaries for zope.container on Python 2.5
Alec Munro wrote: I was just reading that, and am now hunting around on which files exactly I have to modify to pin down the version to 3.8.1. Add a [versions] section to your buildout.cfg: [versions] grokcore.view = 3.8.1 This will pull in a fixed grokcore.view that won't pull in zope.container anymore. 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] movedaddedremoved branches of zope.container and zope.lifecycleevent
Chris McDonough wrote: On 5/18/09 6:42 AM, Martijn Faassen wrote: Chris McDonough wrote: I don't currently have access to publish zope.intid, but I think it's probably ready for a release too, BTW. I just gave you access to this package. Stephan has a script by the way that can give you access to a wide range of packages, might be a good idea if he ran it. :) Thanks. zope.intid 3.7.1 (which depends on zope.lifecycleevent=3.5.2 and zope.location=3.5.4) has been released. Thanks. But: why is this not zope.intid 3.8? It's clearly not a bugfix release. 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] zope.* package dependencies report
Chris McDonough wrote: In SVN, as a result of changes to zope.container, zope.lifecycleevent, zope.location, and zope.intid: zope.intid/trunk/ OK (20 dependencies) (delta -14 dependencies) zope.container/trunk/ OK (30 dependencies) (delta -2 dependencies) zope.location/trunk/ OK (08 dependencies) (delta -0 dependencies) zope.lifecycleevent/trunk/ OK (04 dependencies) (delta -0 dependencies) zope.formlib/trunk/ OK (61 dependencies) (delta -1 dependencies) zope.catalog/trunk/ OK (35 dependencies) (delta -1 dependencies) Cool, the decrease in dependencies for zope.intid is really impressive. Looks like we still have some work to do concerning zope.formlib's dependencies, though. :) 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] zope.app.publication dependencies (volunteersneeded!)
Michael Howitz wrote: Am 15.05.2009 um 13:30 schrieb Martijn Faassen: [...] Cool. It would seem to make sense that the named template mechanism is bundled along with the page template library anyway (instead of the form library). zope.formlib currently depends on zope.app.pagetemplate too so we could easily leave a backwards compatibility import in place. Done. Moved namedtemplate to zope.app.pagetemplate and made new releases of zope.app.pagetemplate zope.formlib Also cut the dependency of zope.app.publication on zope.app.exception by moving ISystemErrorView to zope.browser. Released: zope.browser zope.app.exception zope.app.publication Very cool, thanks very much for doing this work! Looking at the new dependency cycle graphs again. This is the before: http://startifact.com/depgraphs/zope_app_publisher_cycles.svg And this is the after: http://startifact.com/depgraphs/zope_app_publisher_cycles2.svg zope.app.exception is now taken from the graph (good!) Somehow a direct cyclical dependency between zope.app.publication and zope.app.publication now exists where there wasn't any before. zope.app.publication now depends on zope.app.publisher and it didn't do so in the past. Ah, it looks like this was actually a missing dependency which got added about 6 weeks ago. We need to get rid of it... Let's continue with the other refactoring: It looks like we still need to lose the dependency of zope.app.publisher on zope.app.component, or alternatively (or in addition) lose the dependency on zope.app.component on zope.formlib and zope.app.security. The zope.app.security dependency turns out to be only a test dependency, so I just made it such. zope.app.component is starting to look pretty empty. I can see three things still going on in it: * some browser views in zope.app.component.browser. These are to support the ZMI and can stay where they are. * the registration of the zope:view and zope:resource directives. I'm not sure what these are for, as we have browser:view and browser:resource. Perhaps these can be safely lifted into zope.app.publisher, which defines the browser:* varieties * the code in zope.app.component vocabularies. This is support code to create vocabularies for utilities. It depends on zope.interface, zope.component and zope.schema, and zope.app.interface. It might be sensible to move this vocabulary stuff (along with the one in zope.app.interface that we depend on) into a package called zope.componentvocabulary. We can jettison zope.app.component then. zope.componentvocabulary would depend on zope.schema, zope.component, zope.interface and zope.security only. We can then make zope.app.publisher depend on zope.componentvocabulary and lose the zope.formlib dependency, along with the zope.app.security dependency. Anyone wants to work on zope.componentvocabulary? It'd contain zope.app.component.vocabulary + surrounding tests, and zope.app.interface's vocabulary that it depends on. 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] movedaddedremoved branches of zope.container and zope.lifecycleevent
Chris McDonough wrote: [snip] Er, it actually isn't a major release. None of *its* interfaces moved. I thought we were defining major release as API change. Hm, a dependency change isn't a bugfix either. It's an edge case, and one where I think we should err on the side of caution. It's a change in behavior that could have more consequences than the normally bugfix, though less consequences than API change. It could be argued that a change in dependencies *is* a feature change. Less might be registered. People might depend on implicit dependencies being present (even though they shouldn't). Less might be monkey-patched... It was recorded here previously: http://docs.zope.org/zopetoolkit/steeringgroup/decisions.html Moving code around as part of dependency refactoring is worth a feature release (x.y as opposed to x.y.z version number) for the affected packages. Changing an import to make use of a new package that came out of such refactoring is also worth a feature release. 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] zope.app.publication dependencies (volunteersneeded!)
Hi there, I started working on zope.componentvocabulary. It exists now and zope.app.interface and zope.app.component both depend on it, along with zope.app.publisher. We're not entirely rid of zope.app.component yet though: Martijn Faassen wrote: [snip] * the registration of the zope:view and zope:resource directives. I'm not sure what these are for, as we have browser:view and browser:resource. Perhaps these can be safely lifted into zope.app.publisher, which defines the browser:* varieties I need to do some analysis to see where the zope:view and zope:resource directives are in use. I don't want to accidentally introduce *more* dependencies as packages that use these directives would now have to depend on zope.app.publisher instead of zope.app.component, and zope.app.publisher carries around a load of dependencies. 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] zope.app.publication dependencies (volunteersneeded!)
Hey, I need to do some analysis to see where the zope:view and zope:resource directives are in use. I don't want to accidentally introduce *more* dependencies as packages that use these directives would now have to depend on zope.app.publisher instead of zope.app.component, and zope.app.publisher carries around a load of dependencies. I wrote a quick script that uses lxml to parse a whole lot of *.zcml files. I find that these directives are in use in the following places: zope.app.preference/src/zope/app/preference/configure.zcml zope.app.apidoc/src/zope/app/apidoc/codemodule/browser/introspector.zcml zope.app.apidoc/src/zope/app/apidoc/enabled.zcml zope.app.apidoc/src/zope/app/apidoc/disabled.zcml zope.app.publisher/src/zope/app/publisher/xmlrpc/configure.zcml zope.traversing/src/zope/traversing/browser/configure.zcml zope.html/src/zope/html/configure.zcml zope.app.form/src/zope/app/form/browser/tests/widgetDirectives.zcml zope.app.securitypolicy/src/zope/app/securitypolicy/browser/configure.zcml zope.app.http/src/zope/app/http/exception/configure.zcml zope.app.http/src/zope/app/http/configure.zcml zope.app.onlinehelp/src/zope/app/onlinehelp/configure.zcml zope.app.ftp/src/zope/app/ftp/configure.zcml zope.app.dav/src/zope/app/dav/configure.zcml zope.mimetype/src/zope/mimetype/configure.zcml The zope.traversing dependency is a problem today, as I don't think zope.app.component is currently a dependency of this package. It sets up various IAbsoluteURL views. It might actually be the best to move these ZCML directives *down* into zope.component. That won't affect the dependencies of zope.component at all in fact; the [zcml] dependencies of zope.component already need all the dependencies that zope.app.component's view and resource directives implement. 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] movedaddedremoved branches of zope.container and zope.lifecycleevent
Chris McDonough wrote: I don't currently have access to publish zope.intid, but I think it's probably ready for a release too, BTW. I just gave you access to this package. Stephan has a script by the way that can give you access to a wide range of packages, might be a good idea if he ran it. :) 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] movedaddedremoved branches of zope.container and zope.lifecycleevent
Chris McDonough wrote: These branches were merged. I made a new release of zope.lifecycleevent (3.5.2) to PyPI. Thanks very much for doing this work. As a reminder for the future, please do release changes in the API (as in zope.lifecycleevent) as major releases (i.e. 3.6). I realize this requires an extra consideration when releasing that people seem to forget to do, so I've just adjusted the release instructions to make a note of this: (might not have shown up on the web yet, but will soon, step 2) http://docs.zope.org/zopetoolkit/process/releasing-software.html 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] zope.app.publication dependencies (volunteers needed!)
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. Personally I find the whole feature just annoying and overcomplicated. I think the whole feature is due for removal. It's only used in a very minor number of cases and not consistently with views in general. Could you comment on the discussion I've had with Michael Howitz elsewhere in this thread about this then? I think this relates to the whole z3c.template and zope.formlib discussion. [suggestion to invert the dependency between zope.formlib and zope.app.form] Ah, great minds... 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] zope.app.publication dependencies (volunteers needed!)
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. So... what? E... I dunno. The interfaces are: from zope.app.form.interfaces import IInputWidget, IDisplayWidget from zope.app.form.interfaces import InputErrors, WidgetInputError from zope.app.form.browser.interfaces import IWidgetImportErrorView Any thoughts? What would happen if we moved them to zope.formlib and left backwards compatibility imports in place in zope.app.formlib? I think it makes sense for zope.formlib to specify its widget interfaces, and zope.app.form to implement a bunch of those widgets. We can also consider (possibly as a separate later step) moving at least some widget implementations themselves into zope.formlib and just leave the old ZCML form stuff behind in zope.app.form (and a lot of backward compat code). We should only move those things into zope.formlib that don't increase its dependencies though, so we can't move everything. 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] zope.container analysis
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.filerepresentation but depends only on its interfaces IReadDirectory, IWriteDirectory, and IDirectoryFactory. (zope.filerepresentation has 32 transitive dependencies). Heh, zope.filerepresentation has 32 transitive dependencies because they're zope.container's. :) (the only other dependency is has it zope.interface). There's a simple cycle from filerepresentation to container and back. When we looked at them last it's not clear how to resolve them cleanly. Suggestions from anyone? Anyway, this cycle isn't a dramatic one as it only keeps this one package alive. - It depends on zope.app.dependable but depends only on its interfaces IDependable and DependencyError. (note: zope.app.dependable might be a candidate to be called zope.dependable as it depends on no other zope.app packages; it does depend on about 20 other zope.* packages transitively tho). Looking at the graph here: http://startifact.com/depgraphs/zope.container.svg It looks like zope.app.dependable most depends directly on things zope.container depends on through other routes anyway. The exception is zope.annotation. I see you removed the dependency on zope.app.dependable partially by making it conditional. That looks reasonable and should cut out zope.annotation as well. - It depends on zope.publisher, but only its interfaces browser.IBrowserRequest, browser.IBrowserPublisher, NotFound, IDefaultViewName, xmlrpc.IXMLRPCPublisher, and IPublishTraverse. - I was able to break a runtime logic dependency on zope.traversing by disusing zope.traversing.api.getPath in favor of using ILocationInfo(object).getPath(). The rest of the runtime dependencies on zope.traversing are interface dependencies (ITraversable, IContainmentRoot). 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? 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] zope.* package dependencies report
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 order of most-dependencies-to-fewest. zope.introspectorui/trunk/ OK (96 dependencies) I don't think this is actually in use by anyone (remnant of last year's summer of code project that didn't end up going anywhere far), so we can safely ignore this monster. :) A lot of nice work since the last time I did this (mid-2007 or so), when a lot of these packages pulled in the world. Thanks. Work really started taking off in the beginning of this year, and a lot of people have pitched in. Regards, Martijn P.S. You might be interested in looking at z3c.recipe.depgraph. For some reason its sccmap tool spits out unreadable graphs now though, and graphviz's sccmap reduction of graphs to cycles is one of the most useful tools I've found so far in doing this kind of analysis. Not sure what's going on there. ___ 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] zope.container analysis
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 interface dependencies? - 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 zope.container-zope.filerepresentation is a direct circular dependency and that zope.filerepresentation is a package containing only interfaces. So breaking this dependency won't get us much for zope.container. I should've read on before I gave you the same answer. :) We found this out during our analysis during the dependency refactoring sprint we had a few months ago. In this I find graphs an invaluable tool, especially sccmap which I mentioned just now in another reply. OTOH, breaking zope.filerepresentation's dependency on zope.container might be a win (I dont know what else depends on zope.filerepresentation). That I don't know. I don't expect it's much, however, as otherwise zope.filerepresentation would've seen seen in larger cycles during sccmap analysis. 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] zope.app.publication dependencies (volunteersneeded!)
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 dependency between zope.app.publication and zope.app.exception by moving the ISystemErrorView interface and maybe the class which implements it to zope.browser would be better. I'll look into it at weekend. Thanks! [snip] I understand. Why not move the namedtemplate mechanism somewhere else entirely, though? This way we'd not introduce new code. The namedtemplate code itself only seems to depend on zope.traversing, but that doesn't sound like a good home. The tests depend on zope.app.pagetemplate, so perhaps it should move there? This is still a dependency of zope.app.exception anyway, and it itself doesn't appear to depend on zope.formlib. Nice idea. I'll look into it. Cool. It would seem to make sense that the named template mechanism is bundled along with the page template library anyway (instead of the form library). zope.formlib currently depends on zope.app.pagetemplate too so we could easily leave a backwards compatibility import in place. zope.app.pagetemplate might be worth our further attention later, but this at least would clean up a bit more mess as a first step. 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] movedaddedremoved branches of zope.container and zope.lifecycleevent
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 events I moved out are definitely container events. I just wonder if it matters to be completely correct terminology-wise here. The other alternative is to create another package. +1 on merging. I found it rather annoying so far to look for these interfaces in different places. To me it belongs to the lifecycle of an object to be part of a container. +1 too. Even though formally it might indeed be that these events are only container related, I did have the same frustration Hanno describes - these are very common events and often you want to subscribe to them and IObjectModified which is already in zope.lifecyclevents. 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] [Checkins] SVN: zope.intid/trunk/ - Remove a dependency on ``zope.container.contained.Contained``
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 None and declares that the class implements IContained). What's the reason behind this refactoring? Instead of zope.container.contained.Contained the IntIds class now depends on zope.container.interface.IContained plus it redefines the things which are already defined in zope.container.contained.Contained. I do not see why this is better than using the base class. 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 is.. uh.. not complicated, so even if we never do get rid of the zope.container dependency completely, it really doesn't harm anything to not use Contained. Unless you have some nostalgia for it. ;-) Agreed with Chris; IContained interface is very minor and it's easy enough to reimplement. If that helps us reduce dependencies I say let's not worry about this step. 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 implementation could even move to zope.location, actually. Hm, I wonder what code actually *depends* on IContained (instead implements it). Thanks Michael for watching the checkins carefully. Do keep bringing up whatever issue you see here and we'll discuss it. Even if the checkin stands, it can lead to useful discussions nonetheless. 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] [Checkins] SVN: zope.intid/trunk/ - Remove a dependency on ``zope.container.contained.Contained``
Fred Drake wrote: On Fri, May 15, 2009 at 2:57 AM, Chris McDonough chr...@plope.com 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 is.. uh.. not complicated, so even if we never do get rid of the zope.container dependency completely, it really doesn't harm anything to not use Contained. Unless you have some nostalgia for it. ;-) At the rate we're going, every class and every interface is going to be in a separate package. I don't think we have many examples of this. We have zope.browser as a repository of some interfaces. The other such package off the top of my head is zope.broken, and that one really isn't pulling its weight so I hope the IBroken interface can eventually move elsewhere. (someone, analysis please? perhaps we need a package to hold content-specific interfaces, equivalent to zope.browser. IBroken and IContained might move there.. but see below) There hasn't been a lot of splitting off of classes into new packages as far as I know. We moved a lot from zope.app into zope. to leave the ZMI behind, but I don't think that's been a bad exercise at all. 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. Those two goals are not mutually exclusive and in fact mutually supportive. It's not like it was easy to keep a portion in your head before this work started anyway - it was a horrible, horrible, horrible mess. http://faassen.n--tree.net/blog/view/weblog/2009/01/29/0 I'd argue it's easier now that we can actually *read* the graphs. :) The cleanliness of the graph isn't so important if most users still can't understand just because there are so many pieces that they wouldn't normally use directly. I appreciate that point. We shouldn't be generating a lot of small pieces if we can help it. That's why it is important as a first impulse to look at existing packages to move an interface into. Sometimes a dependency inversion is the right way forward. I think in the case of IContained it wouldn't hurt us much moving this interface to zope.location, as IContained is just a marker. It's not as clean as we'd like, but the dependency graph will be much cleaner if we do and it's not horrible either. We want both less packages and cleaner dependencies. I don't think we're moving in the wrong direction at present though, so I don't think it's the time to pull on the package-generation breaks just yet. 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] [Checkins] SVN: zope.intid/trunk/ - Remove a dependency on ``zope.container.contained.Contained``
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 important if most users still can't understand just because there are so many pieces that they wouldn't normally use directly. Yes, I have voiced that concern several times myself. I personally do not even understand where all this fear of installing many packages comes from. I think it is because the ZCML is pulling in too many default registrations and people are afraid of those, which I understand. But to create new packages just because you do not want to use other parts of it is silly. That's not silly at all. I'm not afraid of installing many packages for my applications. But for libraries and little frameworks, I don't like having to depend on 70 other packages even though my library isn't using 99.9% of the code in there in any way. Is that silly? We created zope.container because we don't want to use all the code in zope.app.container. zope.app.container contains the ZMI a lot of code we don't want to be there in our apps as we're not intending to use it. Is that silly? The zope.browser package was created to prevent, among other things, z3c.form from pulling in code from zope.formlib, a completely separate form library. But it wasn't a good situation. People actually got confused and thought they had something to do with each other, in that z3c.form uses zope.formlib, which it doesn't. Is preventing that situation silly? The principle has to do more with *less code* than *less packages*. We're trying to make it possible to use and be aware of less code when considering individual chunks of the code base. To create loose coupling so that you don't have to worry about all chunks of the codebase even though you're only concerned with a little bit of it. To get rid of the code that isn't used a lot (such as the ZMI). If we can make our zope.* packages not rely on a huge amount of other packages that they aren't really using anyway, we stand a larger change understanding them ourselves, and we stand a larger change others might understand them too and adopt them. I could understand these concerns with package creation better if people would point out how the total amount of packages installed for an application or library is increasing (once the applications and libraries have been adjusted to import from the new locations). But I think the amount of packages is decreasing... 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] zope.container analysis
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. Opinions, anyone? zope.browser should not become an iface garbage collector. I think that interfaces not related to browser code deserve a new interfaces package. Sure, that's why I said it's tempting, not that we should do it. When refactoring for dependency cleanup, we should do mechanical analysis about what we could move. We should also always consider whether moving it makes enough sense. And we should consider the goals of moving anything. Chris did the mostly mechanical analysis but didn't speak much about goals. Now I'll do a bit of does moving stuff make sense analysis: I think these relate to browser code: * browser.IBrowserRequest, * browser.IBrowserPublisher * NotFound * IDefaultViewName, * IPublishTraverse This one doesn't: * xmlrpc.IXMLRPCPublisher These don't seem to either: * ITraversable * IContainmentRoot I'm don't think there's a clear case to move any of these, however - these interfaces belong in their packages, and moving these interfaces down into zope.browser would move assumptions into zope.browser about the way the publisher works, and we'd still depend on this stuff with zope.container. Let's think about goals. A possible goal is that we'd like to make zope.container independent from zope.publisher and zope.traversing. This way people who use other traversal and publication mechanisms could still use zope.container's implementation. I think there are realistic chances alternative publication and traversal mechanisms will arise, so I think this is a realistic goal at least to consider. Let's look again at zope.container in that light. It depends on zope.publisher and zope.traversing to support traversing into the container by the publisher. The direct dependencies are: * some test depencencies. these are easiest to get rid of * bits of configuration in configure.zcml that set up the item traverser * related to that, bits of implementation in traversal.py that implement this traversal behavior. * For zope.traversal additionally some of this code is set up in zope.container.testing for reuse. 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 something like that. That is one of these new packages some people object to. :) It would have a clear focus however: equipping the container with traversal behavior so it works with the zope publisher. Alternatively we could keep the code in zope.container and only enable it if zope.traversing and zope.publisher are installed, much like what Chris did with zope.app.dependable. It does worry me a little that this makes the code a bit harder to reason about however, plus it leaves a module in place people who know nothing about the publisher can still run into. Perhaps an acceptable trade off, perhaps not. Looking at zope.container, cutting out zope.publisher and zope.traversing (or making them optional) would allow us to cut the following from zope.container's dependency graph: zope.traversing zope.publisher zope.i18n zope.exceptions zope.authentication zope.browser 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] zope.app.publication dependencies (volunteers needed!)
Hi there, Michael Howitz wrote: z3c.template is used there instead of zope.formlib. I can merge this branch in the next days and cut a release. I'm worried by the amount of *new* code that is pulled in just to reduce a dependency. Making this change would pull in *more* dependencies, not less! Not only do we pull in z3c.template, this package also pulls in z3c.ptcompat, which in turn needs extras to actually work. As Roger says this is a compatibility layer, and that isn't pretty either. We shouldn't pull in new code to reduce dependencies. Any new code added into the Zope Toolkit and that shouldn't be done without a discussion (and not done as a minor dependency refactoring). zope.app.exception defines views that pull in standard_macros. I'm not sure the Zope Toolkit should be concerned with views at all at this stage. I'd like to consider moving the whole page template story off into its own area at some point that is not core to the Toolkit, so it's easy to use other templating systems. The only reason zope.app.publication appears to be depending on zope.app.exception is because it needs ISystemErrorView. It's used once somewhere deep within complex exception handling code. I propose we move ISystemErrorView from zope.app.exception into zope.browser, hopefully cutting zope.app.exception out of the dependency tree entirely. 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] zope.app.publication dependencies (volunteersneeded!)
Michael Howitz wrote: Am 14.05.2009 um 11:00 schrieb Roger Ineichen: The last option I already implemented on the icemac_no_formlib branch in zope.app.exception. z3c.template is used there instead of zope.formlib. I can merge this branch in the next days and cut a release. As long as z3c.template depends on chameleon, lxml etc. I think this is a no go for core zope packages. According to its setup.py z3c.template does not depend on chameleon. It depends on z3c.ptcompat [zpt] which does not depend on z3c.pt but only on zope.app.pagetemplate. I still think there's a problem in pulling in 2 more packages. zope.app.exception is not a big package in the amount of code inside.. Could you talk a bit about what your branch is trying to accomplish? (see elsewhere on the thread for a way to cut the dependency of zope.app.publication to zope.app.exception completely with little effort) 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] zope.app.publication dependencies (volunteersneeded!)
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 has many many dependencies but only this special function of it is used by zope.app.exception. It's needed to render customizable the unauthorized views. So I replaced zope.formlib by the much more lightweight z3c.template. Is this replacement compatible with zope.formlib's namedtemplate mechanism? Will anything break? The guaranteed compatible step forward to reduce dependencies would be to extract the namedtemplate mechanism from zope.formlib and place that somewhere else. zope.formlib can then have an import for backwards compatibility. See also the proposal http://mail.zope.org/pipermail/zope-dev/2009-April/035833.html I missed this discussion then, my apologies. I still stand by my opinion that this would suddenly pull in *new* libraries in with a significant chunk of new code, and we need to be very careful with that and not just do it to lift a dependency. (see elsewhere on the thread for a way to cut the dependency of zope.app.publication to zope.app.exception completely with little effort) This (move the ISystemErrorView) seems to be the right solution to get rid of the zope.app.publication dependency on zope.app.exception. In a project of mine I need zope.app.exception independently of this dependency but I do not want to depend on zope.formlib for a little feature of it which can be done by another smaller package. I understand. Why not move the namedtemplate mechanism somewhere else entirely, though? This way we'd not introduce new code. The namedtemplate code itself only seems to depend on zope.traversing, but that doesn't sound like a good home. The tests depend on zope.app.pagetemplate, so perhaps it should move there? This is still a dependency of zope.app.exception anyway, and it itself doesn't appear to depend on zope.formlib. zope.app.exception's UI bits are a curious case in that they're not really part of the ZMI, though they integrate with the ZMI and assume the existence of some macros. It's also a zope.app.* package and we'd like to get rid of those in the toolkit. What to do with it? 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] ZTK futures: one big package?
Hi there, Patrick Gerken wrote: [snip] I do not want to abuse you here as a support forum for pypi, but would it be possible to publish a new release, but without providing the distribution files? The intention would be, not the break the installations with pinned versions, That would never happen anyway, unless you removed existing releases. but breaking attempts to get the newest versions, because the distribution files would be missing. I believe buildout has an option to prefer final releases. If you release a non-final release (beta, alpha) and people use this option they won't get your version even if they do not use a list of pinned versions. But that doesn't look like what you want. The people might then check the webpage of pypi, where the readme would state that the package has been discontinued and can be found in package x.y. As a next step, pypi might offer some way to ignore these packages in searches. That's like what Chris suggested with a potential supersedes and replaces metadata for packages in PyPI. PyPI doesn't really support this yet. I think you could simply release a package that issues a deprecation warning when it's in use. That way people will know to look somewhere else. Note that there's also work done on the test runner (don't know the state, Christian Theune is working on it) that can report on improved import locations for a codebase (if you were importing from zope.app.component something that's now in zope.site, it will tell you). 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] ZTK futures: one big package?
Chris McDonough wrote: Another thing is this: even if we're successful in teasing out dependency info so we do have a collection of truly independently useful things, after it's all over, we're going to get to a point one way or another where we make a big package of stuff that just can't have its dependencies teased apart because it *really is just one thing*. Why *not* just do it now? That's why I suggest a ZMI project (or doing away with the ZMI entirely if nobody's interested). That's really the main thing creating entangled dependency structures. I want to create a grokcore.view that doesn't depend on a thousand Zope packages and a ton of Zope code. That's because grokcore.view doesn't need all this stuff. Right now it gets it indirectly through tangled dependencies. We need to try porting it to the latest set of releases and see whether that helps. Once that's done, we need to cut a few more dependencies, and there we are. If all those packages are maintained as a single large ball, I cannot do this analysis. In the current setting, we have experience with this analysis, we have tools to do this analysis. Additionally, I'd need to do a lot of work separating things again in order to release grokcore.view if I were to do the work in a singly maintained ball. But you also said that there's no need to maintain this *just* as a single ball. That is, we could have something similar to the current Zope 3 project that pulls in all the other packages as externals and that we release to PyPI. I'm not sure what this gains us currently. Who would be using this package? Are you suggesting we remove all the other stuff from PyPI or something? Finally, an independent package can be useful by itself, with clear dependency structures, even though it's only useful for people who buy into quite a few of the other packages that you don't want to buy into. Such is the case for zope.site. 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] ZTK futures: one big package?
Chris McDonough wrote: [snip extending configuration patterns instead of replacing wholesale] Often this code makes the subframework tremendously complex, and the subframework grows inappropriate dependencies along the way. *Sometimes* the situation gets so confusing for a new user, they just quit and go use something else. I am curious about your use of the word often. I think what you describe has happened for the example you give, namely the publication/traversal stack. I think it also has happened to a certain extent for the user authentication story. I'd like to identify other such nasty grown subframeworks and you seem to know about a few more. I think in part this happened because there wasn't enough documentation about wholesale replacement patterns (and not enough documentation period), and in part it happened because the APIs or component relationships were just not designed as well as we'd like (as you remark below), and in part it happened because people often don't *want* to do a wholesale replacement but exactly the kind of only reconfigure this bit you describe This is a pattern that happens over and over again in Zope development. In my personal opinion, the original error was trying to make the subframework configurable at all. Instead, the subframework should be replaceable easily, but it should itself be relatively rigid. At very least, for subframeworks that really do require extra configuration (should be very few), this configuration should be done via highly specialized ZCML directives (or grokkers), as opposed to some very general adapter registration that can't be easily discerned from other adapter registrations by a newbie. I agree that specialized ZCML directives and grokkers are a good thing. I think we had too much of a tendency to get away from those and instead generalize everything. I think we should define clear Python APIs for particular configuration concepts, not just ZCML directives or grokkers. In turn the ZCML/grokker implementations can use this Python API and be really minimal in themselves. That said, I do think there's implementation value in a general registry. It's just not a great API in most cases. If the subframeworks were more rigid (but replaceable), the *intent* of the subframework author could be more easily discerned, and fewer people would fall into the trap of adding more configuration code to a subframework instead of just replacing it entirely. And fewer people would just walk away in frustration. While I understand the sentiment and I agree with the general advice, I again must note that sometimes it's useful to be able to configure a subframework. everything as normal with just a few tweaks is after all a good way forward in many cases. The idea you are promoting is clearly focused frameworks. They do one thing well, and are configurable in a few ways and clearly replaceable too. What does this have to do with packaging? Well, currently, there's a dizzying number of packages that make up the ZTK (nee Zope 3). Each of these packages is a pure peer of all others in a PyPI listing with no real way to get a sense of their relative importance other than performing a linear audit. One way to get some hints is to look at a dependency diagram and see which ones are lower down in the stack. Even if a user *does* do a linear search of all of them, it's still awful hard to discern for some new user which ones are important, and which ones just happen to exist by some inequity of history without trying to install it. The user needs to gain some holistic knowledge of the system in order to discern the important bits from these historical inequities. Most new users understandably just walk away from *all* Zope packages before they gain this knowledge; it's just too hard for them to tell the difference between the truly important and reusable bits and the stuff that just happens to be packaged up and released but which is useless outside of some highly specific context. In effect, we just don't communicate *intent* very effectively in our current packaging structure. Sure, agreed. In my opinion, this is why a lot of Python developers who are otherwise very smart have given up on trying to use Zope packages. The time required to figure out which ones are useful and which ones aren't is just too high. It's way easier for them to write them all off wholesale and just write what they need from scratch or use somebody else's software. Good developers tend to like small, useful libraries and frameworks. Agreed again. We can ameliorate the situation in a few ways: - We can reduce the number of distributions. - We can make each current Zope package distribution independently useful. My suggestion is that we do the former first in order to communicate *current intent* (the state of reality right now). We can
Re: [Zope-dev] ZTK futures: one big package?
Hey Chris, Chris McDonough wrote: On 5/12/09 4:44 AM, Patrick Gerken wrote: [snip] I don't think there will ever be a point where it's finished; at least not in any time frame in which Zope is still relevant at the end. Sure, we can keep the current setuptools distributions and keep pulling apart their respective dependencies forever, but by the time it's all over, it just won't matter anyway; folks will be happily using Django 3000 or Pylons 4, which will have recreated all the features we teased out. Such skepticism. Please consult the following (non-reduced) dependency graphs (of released packages): http://startifact.com/depgraphs/ I've picked a few high-level components like container and catalog. They depend on a lot, yes. Too much, yes, there are bits that can still be teased out from that graph (in particular I think we should make the container stop depending on the publisher). But they also depend on a lot because they're fairly high-level components that do quite a few things. I realize that many of these packages are not useful for a random Python developer. But I don't believe we have to ensure all our packages are useful in that way. We just have to create more of them. I think all of the ZMI stuff should either be eliminated or consolidated. That would allow us to lose zope.app.* packages. Remove them from PyPI, no, though - we already crossed that bridge and can't break everybody's code. I think these high-level components and a few more is what we can at least base a future release of Grok around. (with a compat package that pulls in a lot of the zope.app. packages to make sure the existing code doesn't break). The dependency graph will still be huge, but it won't be as crazy as it is with the current Grok release. 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] ZTK futures: one big package?
Hey, Chris McDonough wrote: [snip] If your package depends on zope.app.publisher, you get *78* eggs. 63 eggs these days, by my measurement. Still far too many. I think with some effort we can chop off quite a few more. Look here at the main cycles in that graph (this is the cause of a lot being pulled in that shouldn't be): http://startifact.com/depgraphs/zope_app_publisher_cycles.svg It looks we need to pull more out of zope.app.component somewhere else so zope.app.publisher doesn't need to depend on zope.formlib anymore. Probably ZMI stuff holding things in. The other tricky line is the dependency of zope.app.publisher on zope.app.publication. Change that install_requires line in your package to ZTK and you get the same software. OTOH, packages that rely on things that are *truly reusable* like zope.interface, and so on will need to do nothing; those packages will continue to have a life of their own. I'm worried that one person's truly reusable is another person's package that is really useless without a huge amount of buy-in. 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] ZTK futures: one big package?
Hey, Patrick Gerken wrote: [snip] Wouldn't it be possible to put them on a dedicated pypi? pypi.support.zope.com http://pypi.support.zope.com? Yes, but not without breaking backwards compatibility with a lot of released buildout.cfg files, and having to arrange our own mirroring services and so on. (and definitely not on zope.com. zope.org, yes) I start being scared of using pypi. Why? 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] ZTK futures: one big package?
Hey Chris, What about the following alternative suggestion to alleviate some of the underlying issues you point out. I agree we are signaling badly which packages are interesting to newcomers and outsiders and which packages aren't. In part we've already done the damage with the packages in the zope.* namespace. I think we shouldn't try to put humpty-dumpty back together again marketing-wise by removing those packages a few years after their release, and whether this is worth the effort (and I see negative drawbacks to doing so). What we can do is start to clearly indicate on top of a package's documentation whether it's intended to be independently reusable outside of a Zope context or not. We should do this on pypi, but we should also back this up by writing narrative documentation for those packages we *do* think are independently reusable by a wide audience. I think this should be done by starting 'doc' directories in those packages and putting in sphinx-based documentation. The next step would be to go to our non-reusable packages and start writing narrative docs for that, ideally with example projects. If we pick a few likely candidates and do some more refactoring we may be able to salvage them into reusable packages and we can declare them as such. As indications I propose: This package is intended to be independently reusable in any Python project. It is maintained by the Zope Toolkit project. (with hopefully appended: For more documentation on this see narrative docs.) This package is at present not reusable without depending on a large chunk of the Zope Toolkit and its assumptions. It is maintained by the Zope Toolkit project. We can also add 'reusable' to the metadata tags in PyPI in addition to 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 )
Re: [Zope-dev] ZTK futures: one big package?
Tom Hoffman wrote: The implementation details are over my head, but what SchoolTool needs is a middle ground between one big package and a giant pile of little ones, because our primary deployment strategy is via Linux distribution packaging, in Debian/Ubuntu in particular. Currently, Fabio maintains an official monolithic package for Debian, and we generate a giant pile of .debs from eggs and keep them in a PPA. Because there is administrative overhead with every package, even if we can eventually come to consensus on the desirability or pushing 70 tiny packages into the Debian pipeline, it may never be practical. So a single, community-recognized ZTF that would be the foundation of manageable packaging for Linux distros would be a huge win for us. That's a good point. I can imagine this giant .deb is created from a combination of a KGS list of versions and downloading them together. But having a clearer picture of which packages we truly mark as reusable outside of Zope would also help inform the decisions on what to package for debian as seperate packages, and what to package as a whole. 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] ZTK futures: one big package?
Hey, Chris McDonough wrote: [snip] I'd hope you'd agree that given a perfect world where packaging structure backwards compatibility was not a concern: - The original distribution structure was a mistake. - Changing it would be a bugfix. I think we should've gone for an approach where we slowly peeled off independent packages from a big ball in iterative fashion, instead of the giant explosion we ended up with. (assuming the tools allow us to do so) Whether changing it back now would be a bug fix: I don't know, for two reasons: * we have the ability now to do fine-grained bugfix and feature releases of individual packages without having to coordinate all code. This of course is also a minus, sometimes. * more nebulous: I do find that the explosion, for all its flaws, helped us with identifying bad dependencies. Peeling off packages would allow us to do this too, however. That said, given your other arguments in prior mails today, I'll give up agitating for any packaging changes on this maillist, because it's pretty much impossible to argue against the article of faith that there is some presumed majority of thousands-of-people-who-depend-on-those-packages-as-distributed-now-and-whom-will-forever-want-to-do-so-and-whose-world-will-explode-if-we-take-them-away. meta: I don't like how you say that this is an article of faith, because you seem to imply that we're superstitious with this. Concretely I have quite a few codebases around that depend on the current package list being present. They'd stop working if we suddenly withdrew these packages from PyPI. I think there are quite a few others in the same position. Maybe when setuptools grows provides and obsoletes setup parameters (ala RPM), this particular problem can be solved better technically. Yes, something like that would probably help. [snip] As indications I propose: This package is intended to be independently reusable in any Python project. It is maintained by the Zope Toolkit project. (with hopefully appended: For more documentation on this seenarrative docs.) This package is at present not reusable without depending on a large chunk of the Zope Toolkit and its assumptions. It is maintained by the Zope Toolkit project. We can also add 'reusable' to the metadata tags in PyPI in addition to this. I think this is a reasonable workaround if the packaging structure does not change. I'll start putting up a few of these notifications today. 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 )
[Zope-dev] reusability markers in our documentation
Hi there, In the ZTK futures thread Chris McDonough pointed out that right now we don't signal which packages are easily reusable outside of the Zope Toolkit and which packages aren't, and need a great knowledge of the way the Zope Toolkit works and a large amount of installed packages. In order to increase our focus on reusable packages that stand on their own, and to reduce confusion by the outside world, we should signal clearly which packages should be considered by the broader community, and more importantly, which packages they can safely ignore. I've therefore created the following guideline in the Zope Toolkit decisions document: Some Zope Toolkit packages are quite reusable without having to buy into the rest of the Zope Toolkit. Others aren't reusable at all without pulling in a huge chunk of the Zope Toolkit; they depend on many assumptions. We should communicate this clearly to potential users. As a first step, we will make sure these notifications are available on the PyPI pages. We will do this by adding a message about reusability to the long_description (which gets displayed on PyPI). Typically this is done by modifying the package's README.txt or ``src/zope/../README.txt`` doctest. The following text should be used for reusable packages:: *This package is intended to be independently reusable in any Python project. It is maintained by the* `Zope Toolkit project http://docs.zope.org/zopetoolkit/`_. The following text should be used for packages that are *not* easily reusable:: *This package is at present not reusable without depending on a large chunk of the Zope Toolkit and its assumptions. It is maintained by the* `Zope Toolkit project http://docs.zope.org/zopetoolkit/`_. At the time of writing, most of our packages will be marked as *not* reusable. Only packages at the roots of our dependency tree that have a clear purpose and some documentation (such as ``zope.interface`` and ``zope.component``) should be marked as reusable. We will slowly start to build up from there. Help is needed to mark these packages. As a safe assumption, all zope.app.* packages should be marked as not reusable. It's a simple matter of going to the setup.py, seeing what file ends up being the start of long_description (typically README.txt or something like that) and modifying it with the marker text. I've marked zope.component, zope.interface and zope.schema as reusable. That doesn't mean their documentation shouldn't be improved to support this; it should. But nevertheless it's pretty doable to reuse them today. We have more such packages; in case of any doubt about the status, please bring it up in discussions here. I've marked zope.app.publication as not reusable already. Volunteers to help mark the other packages? 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 )
[Zope-dev] zope.app.publication dependencies (volunteers needed!)
Hi there, zope.app.publisher is depended on by quite a bit of code that uses the Zope Toolkit, as it defines brower:view and browser:resource and the like. Unfortunately zope.app.publisher currently depends on more than 60 packages. This is rather excessive, and we'd like to cut down on this. Also interesting about zope.app.publisher is that while it defines a 'browser' directory it actually doesn't contain any ZMI code; instead ZCML directives are defined there. Refactoring so the ZMI isn't around anymore is usually a good first step, but that's not needed here. If you look at the dependency graph for zope.app.publisher the task of fixing this looks daunting: http://startifact.com/depgraphs/zope.app.publisher.svg But now please observe the following: http://startifact.com/depgraphs/zope_app_publisher_cycles.svg This identifies the main cycles in that dependency graph. If we break those in the right way, we can cut down a lot of dependencies in one go. Getting rid of the zope.app.form and zope.formlib dependencies looks like a sensible step. From this little graph, it looks clear we could do some of the following things (research is needed to see how difficult they are): * cut the dependency of zope.app.publisher on zope.app.component * OR cut the dependency of zope.app.component on zope.formlib * cut the dependency of zope.app.publisher on zope.app.publication * OR cut the dependency of zope.app.component on zope.app.security * cut the dependency of zope.app.publisher on zope.app.publication * OR cut the dependency of zope.app.publication on zope.app.exception * OR cut the dependency of zope.app.exception on zope.formlib There are probably a few more options there, but given that small graph, you get the picture. Any volunteers to do this research on how hard some of these steps would look and report back here? Once we've discussed the options we can proceed fixing the problem. 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] ZTK futures: one big package?
Hey there, Tres Seaver wrote: [snip] I think we need to clarify terms / triage the sets of packages we are talking about: Sure, agreed, though I think we can already work with 'reusable' and 'not reusable' right now as hints to users. The 'not reusable' group consists of 'wannabe reusable' and 'implausible it'll ever be reusable'. I also expect we'll end up with some packages that have reasonable dependencies but still a *lot* of dependencies - does that mean they're reusable or not? If not, what if Grok still needs one? I'd be happy to see someone triage the existing set of packages in the categories Tres proposes. - zope.app.container (Products.Five.browser.adding) Should be easy enough to move to zope.container, hopefully. - zope.app.form (Products.Five.form.*) This actually isn't that bad in the reusability department; it's mostly a bunch of widgets. Not that it's the be all end all form library by a long shot, and most of our libraries shouldn't be depending on it, but it's not a bad thing to have it in the ZTK for now. [snip] I'm not enough up on Grok to do a similar analysis there. Grok is mostly split up into grokcore.* packages which list explicit dependencies in their setup.py. I think grokcore.view is holding in the most dependencies at the moment. 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] ZTK futures: one big package?
Hey, Chris McDonough wrote: Instead, I have argued for promoting packages that have some life of their own (independent of the rest of the pile) into subprojects that have their own release cycles. Then outside projects such as Plone and Grok could depend on independent versions of such packages, giving them slightly more flexibility than requiring a version of the ZTK. We already have that flexibility today. To me, the utility of a release of version numbers in the ZTK does not at all exclude the potential to evolve the packages to more independent sub-projects. Given that this suggestion has been met with skepticism, let me try another tact. I think that's an inaccurate description of the response you got. I'm quite positive about trying to give as many packages as possible a life of their own. I don't think you got anyone else arguing against this point of view. I'm also quite positive that some packages are: * useful as independently distributed packages * only make sense in a Zope 3 or a Grok or a Zope 2 context, i.e. they depend on a significant set of Zope packages. I'd like to get out of this paradigm: * the Zope packages are independent sub-projects. * therefore we cannot distribute a list of versions that work best together. And this one: * if we distribute a KGS of anything * packages in that anything aren't independently reusable automatically and should be merged into a ball. I'd also like to get out of the following paradigm: * the Zope packages are not independently reusable yet * therefore we should distribute them all together We're in a grey area. Some package are here, some packages are there, some are in between. Some packages build on other packages, but have clear dependency structures. Some don't have clear dependency structures. Some have better documentation and better focus than others. If there is to be a merging of code together, then I propose we continue the project where the ZMI code is merged into one or a few packages. We can also investigate merging 2 or 3 packages together where it seems to make sense, or simply moving code between packages (some code needs to go down the dependency list, some up). Instead of thinking about it this way, could we think about it as *deflating* the current set of zope.* packages that do not currently have a meaningful life of their own into a single setuptools distribution named ZTK. This package would include most everything in zope.app*, plus things like zope.server, zope.publisher, and other things that just aren't useful outside of Zope-the-appserver, or which currently just depend on too much. -1 This would make it a lot harder to: * clean up dependency relationships with the goal of creating more reusable code. We'd all hide them in a sumo ball again. * get rid of bits we *don't want anymore*. If I need anything in a sumo package I'd need *all* of it. * override individual packages with newer versions * we've done a lot of refactoring recently trying to separate the UI from packages. This is done by creating a *new* package, leaving the old package behind. We can do this, test this and release this package-by-package now. Over time, we'd tease out the dependencies of packages that live in the ZTK distribution, making them useful outside without any dependency on the ZTK. The names of these packages could be arbitrary (they wouldn't need to retain their old zope.* names). Some backwards dependency shims would be added to the ZTK to prevent old imports from breaking, and the ZTK distribution would then just have a dependency on the thing that got broken out. I don't like the attempt to redefine what the ZTK means to a giant ball of Python packages. That's implying that, say, zope.component is *not* in the ZTK. That's wrong. Why generate a whole lot of work for ourselves getting from where we are now to here? We've learned how to work with the current situation in 2007 already. I'm thinking that this would simplify things greatly for people who want to be consumers of truly independent Zope packages. There'd be exactly N of them available for download (where N is much less than 100, more like 20), plus the ZTK, which would have the rest of the pile in it over time. I don't see why a big package would simplify things greatly for you or anyone else. If someone wanted to use a forked version of a package that lived in the ZTK distribution, they'd either do so by teasing out the dependencies and making it truly independent or they'd just reroll a custom version of the entire ZTK distribution. And that's easier than the current situation how? Are you really proposing we destroy the dependency information we've already teased out and then make people do the work again? Does this make any sense? Not a lot in my book. I think an important reason why there's so much awareness of dependency issues in the
Re: [Zope-dev] ZTK futures: one big package?
Hey, After reading this, I thought of one benefit that having a larger package would have: it's somewhat easier to refactor for dependencies, because all the code will be in a single checkout and all the tests can be run together, and the fixed release can go out as a single release. Having done some dependency refactoring I can see the benefit of that, but I also think it is not a great benefit given the capabilities of buildout-driven development and some of the tools we have (such as compattest). We'd certainly give up a lot just to gain that benefit. 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 )
[Zope-dev] buildbot web page
Hi there, There are various buildbots running for Zope-related stuff. The problem is that they're only mentioned on mailing lists and such so nobody remembers where they are, how to use them, and who to contact. Could someone work with Sebastien Douche who is maintaining one buildbot and record what's going on? http://zope.buildbot.securactive.org/ http://grok.buildbot.securactive.org/ (missing repoze and zc.builout) You can record it in a page in the zopetoolkit area in SVN. If you're feeling ambitious you could also look into using snakebite for testing some of our packages on a large range of platforms. Regards, Martijn P.S. I'm not in charge of the buildbot story. At all. I'm just trying to get others to take some responsibility in documenting it and promoting it. I'm not even a user really at this point. I want to be one, but I need a web page telling me where to go. :) ___ 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] a buildbot for compatibility testing
Hey, Sebastien Douche wrote: [snip] * there's a buildbot http://zope.buildbot.securactive.org/ http://grok.buildbot.securactive.org/ (missing repoze and zc.builout) Thanks. Could you add a page to the zopetoolkit documentation about this please? Otherwise again I will look through the email archives to remember. If you want to, please add yourself as a point of contact. :) 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] dropping Python 2.4 support in the Zope Toolkit?
Hey, Martin Aspeli wrote: I'd be happy with that kind of policy. Maybe you can help Sebastien Douche document the existing infrastructure in the zopetoolkit website. It just has to be a page with a few paragraphs so we won't keep *forgetting* that this exists and people can find out about without reading everything on this list... 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] dropping Python 2.4 support in the Zope Toolkit?
Martin Aspeli wrote: Martijn Faassen wrote: Martijn Faassen wrote: In order to get to a conclusion: I haven't seen convincing arguments yet *not* to drop the Python 2.4 for new releases of the Zope Toolkit libraries. I'd like to phrase the debate in those terms instead of the reverse, because ensuring Python 2.4 compatibility is an additional burden for developers and we need good arguments for *not* dropping this burden. Since I haven't seen such arguments besides the Plone 3.x related ones, I will amend the zope toolkit decisions about this. We've had some more discussions about this and the Plone release schedule. The upshot is that if Zope 3/Toolkit drops Python 2.4 support, it will effectively render it inaccessible to Plone users for the next 12-18 months. As I pointed out, it is effectively inaccessible for Plone users anyway, as Zope 3 is already installed. You *cannot* mix Zope Toolkit and Zope 3 libraries just like that and expect anything to work. I agree that some of the refactored ZTK components don't make sense if they're bundled with Zope 2.10 in pre-refactored form. Yup, they won't. However, the idea is surely also to support new and more focused components in the toolkit. There are no such new and more focused components even on the drawing board yet. I highly doubt that the first release of the Zope Toolkit will contain such components. We're not comfortable moving to Zope 2.12 for the 3.x series. We may be able to move to Zope 2.11, which *may* work with Python 2.5, but this is not clear. That makes the potential user base for new-and-dependency-isolated Zope components quite a bit smaller. I don't believe in this Plone (for *existing Plone releases*) user base anyway, so I don't think it's getting smaller. If we'd have released a Zope 3.5 that didn't have Python 2.4 support, would you have complained that you cannot use Zope 3.5 with an existing Plone release? This is the same as trying to use Zope 3.4 and Zope 3.3 components together (though the changes from Zope 3.4 to the Toolkit are *bigger* as we move things around). It *might* just work in some cases, but it's unlikely it will. At the end of the day, it may not make much of a difference. However, I am still puzzled as to why we you are trying to base a decision on arguments *against* breaking compatibility. The main argument *for* dropping compatibility seems to be a hand-wave towards an added maintenance burden. Is that really so? Are we struggling to release components that work across Python versions? Sorry, I won't let you turn this back around again. :) Arguments for increased maintenance burden will need to be realistic. I will note that Grok 1.0 won't work with the Zope Toolkit either; we're sticking with Zope 3.4. Only after 1.0 will we go over to the toolkit. If there are Python 2.5 features we really want to use, then I understand. Otherwise, I think as a general principle it makes sense to always aim for the widest amount of compatibility possible, at least when it comes to the core Zope Toolkit, which, by its very nature, aims to underpin a number of heterogeneous platforms with different constraints. I'd rather hope Plone was considered one of those platforms. ;) It is, but again, it's just wishful thinking that the toolkit libraries as they are released today will work in combination with a existing release of Plone. 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] dropping Python 2.4 support in the Zope Toolkit?
Wichert Akkerman wrote: [snip] But you can use a lot of the Zope Toolkit with Zope 2.10, which is an enormous benefit. No, you can't, as far as I can tell. You'd have to remove Zope 3 entirely from Zope 2.10, and Plone relies on Zope 3, so this sounds unfeasible. The burden of evidence is on the people making this claim. If that was not possible a lot of the things people want to do with Plone would not be possible. I don't understand what you're saying here. 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 )
