Hi there, Chris, I think you are misunderstanding my position quite dramatically. Perhaps you should calm down and reconsider what I've been saying, as I believe we're a lot closer than you seem to think.
On Tue, Mar 3, 2009 at 8:42 PM, Chris McDonough <chr...@plope.com> wrote: [snip] >> I'd rather have one underlying action API that did the minimal but right >> thing in zope.component that grokcore.component and repoze.zcml and the >> Zope Framework (with its additional requirements for security) can all >> build on. > > Why does it *have* to be in zope.component? What magic does this name imply? It doesn't, but it should then be *removed* from zope.component into some other package (which could be repoze.zcml for all I care). I don't want there to be a duplicate implementation laying around and I'd like there to be a clean dependency structure. At the same time, directives need to exist that are compatible with the Zope Framework. It'd be nice if there wasn't a duplicate implementation of their actions. [snip] >> And you think it's all due to the brand... > > Yes! Someone who *wants* to use basic ZCML directives but doesn't want > zope.security, zope.location, zope.publisher, zope.traversing, zope.i18n, and > pytz can *already* use repoze.zcml; the only thing they don't get here is the > brand. Yes, why are you explaining this to me? For a year now people could use grokcore.component, where they could register their objects without pulling in those dependencies as well, and not having to deal with a lot of ZCML either. > Why should we punish the folks who are already using the zope.component > directives with security in them by changing them in order to service some > goal > of fidelity with brand? Who cares what it's called? I'm not talking about the fidelity of the brand. If you use repoze.zcml or grokcore.component today you'll use two implementations of the actions and in the case of repoze.zcml, two implementations of the ZCML directives. Granted those are very minimal in grokcore.component and mostly the registration functions themselves. But repoze.zcml contains wisdom about certain WSGI situations that grokcore.component and zope.component don't have. What I'd like to do is consolidate all that wisdom about how things should be registered in *one* place (I don't care what it's called, and it *could* be zope.component or repoze.zcml) and then build grokcore.component, repoze.zcml and Zope 3 on top of this. That way they all share the same underlying technique, including your multi-app support. It appears to be the coordination overhead required seems to make this impossible. Even you who should have an interest in not carrying in the ZCML implementations in zope.component as they're duplicating and possibly confusing users of repoze.zcml seem not to agree that it'd be nicer. [snip] > I don't know what's so hard to understand about this: not everyone wants to > use > the ~78 packages that currently make up "the Zope framework". This is the > entire point of what I'm saying. Very few people will never care about "the > Zope Framework" in entirety, if it's defined as you define it above. I'm talking about zope.component here, and you don't seem to want to change that either. I'm trying to see the big picture of the different users of this package and think about ways to arrange it so that it'd be better. Less redundant code, more shared code. You don't seem to be interested in that, because to you the problem is already solved. I understand that, but I also don't understand your resistance. > 99% of people in the Python community *dont use anything related to Zope* and > *WILL NEVER USE ANYTHING FROM IT IF IT'S ALWAYS A BALL OF 78, 60, OR EVEN 10 > PACKAGES*. If you're defining "everyone" in your sentence above as "everyone > who already uses Zope", I believe that is incredibly short sighted. We could > do > so much more if we ditched the notion that the big glob of packages you're > trying to recast as "The Zope Framework" is of more value as a glob than as > individual packages that any Python programmer could use. Please don't yell at me. I don't take the position that you think I am. You're telling me things I already agree with. Why do you think I care so much about clean dependencies in the Zope Framework? Because I want people to be able to enter the Zope Framework at any point in the tree. People who don't care about the rest. Because I want the tree to be simpler so that Grok uses less of it and I can understand more of it. But that takes coordinated effort as we do have people using the entire tree and we don't want to leave those with a broken system. I'm taking both perspectives at the same time. I don't think they're mutually incompatible. You're doing this thing called Repoze. That's a lot of packages and presumably they share a few philosophies and you make sure they tend to work together. At the same time people can pick up on individual packages. Why can't we have something called the Zope Framework that does the same for Zope packages? Do you really think we should forget about any backwards compatibility and all move over to repoze packages today? I'm not quite sure what you expect here. >> Forking is one way to solve the problem and forget about it, if you >> don't care about compatibility with the Zope Framework. That's fine. >> It's something you have the freedom to do of course and undoubtedly you >> are much happier with it. It's also unfortunate for me, as your >> improvements are not making in into the shared component. > > But... but... you can already use this stuff. How does that not help you? It > just doesn't have the Zope name. But it's already perfectly usable both > inside > and outside The Zope Framework (see repoze.catalog, repoze.session, > repoze.zodbconn, repoze.who, repoze.tm2, repoze.sendmail, repoze.retry, > repoze.errorlog, repoze.evolution, repoze.folder, repoze.debug). If you > really > believe what you say above, you are *choosing* to not use it until it has a > Zope > brand attached to it. The entire *point* of this stuff is that it's possible > to > use it both outside a Zope application server *and* within it. It may not be > compatible with some *old* implementation, but that doesn't make it > *unusable*. Why do you think I've said these are unusuable? Please cut out this whole set of allegations concerning brand. Grok is using the Zope implementations because we've been using these implementations for years now and we can't just replace with something new just like that. I also prefer to invest my time in improving the original implementations to make progress, but I'm quite open to putting in new implementations over time if they prove better and there's a backwards compatible path forward. I think the Zope Framework should also be open to such decisions to include Repoze components and use other implementations, though there are some community and legal hurdles to be cleared. I might of course lose hope in the ability of the Zope developers to get organized and produce something that I think is a long-term good foundation for Grok. In that case breaking backwards compatibility might be the best step forward, but it'd mean an enormous loss to me of components I'm already using in various applications I'm maintaining. I haven't given up hope in the Zope developers yet though, so I'm doing my best to improve the situation. > We could do the same for new Zope packages and get a lot more traction without > dragging all 78 packages behind us as we move forward. I have a lot of code that needs to work. I'm doing the best I can in trying to improve the code that we already have so we don't have to pull in all 78 packages or whoever many they are. I hope eventually more of the grokcore.* libraries besides grokcore.component won't have to pull in the full set, but we aren't there yet. I'd like there to be a community that is capable of making such changes and other ones. >> So while the problem is solved for you, it isn't solved for me. Grok has >> different goals concerning compatibility with the Zope Framework, and >> therefore more interest in improving the underlying framework itself. > > Improvement of "the framework" does not always need to take the narrow shape > of > changing the code inside Zope's SVN or coming up with a new zope.* package. I think there's sufficient evidence that I'm aware of this, though I must say I'm happy enough working in Zope's SVN. Sometimes Zope packages need to be improved, and what's the problem with coordinating that effort? >> These are different philosophies. You with your philosophy should have >> no problem with me trying to improve the framework experience though, as >> you can go off on your own anyway and cooperate on bits of it whenever >> you want. So I find it frustrating to hear you say "no" so much now > > I have no faith whatsoever that staying on the course we've been on for the > last > 9 years (large interconnected codebase, backwards compatibility at all costs, > lack of any consumable documentation at a package level, not much curiosity > about how other Python web frameworks work, not much real cooperation with > folks > that maintain other Python web frameworks, a constitutional inability to > attract > new users) will bring any sort of positive change. I see the canonization of > "The Zope Framework" as a big ball of interconnected code a continuation of > this > pattern. We could do so much more if we just decided to become a part of the > larger Python world by decentralizing. But c'est la vie. I'm very bad about communicating my proposal if you think that's what I've been proposing or if that is my position. I think you should know better given my actions. I am really scratching my head that a proposal that is aimed to make *more* of these packages available to you on a package level without pulling in a whole set of unrelated dependencies gets all this resistance from you. Right now we are maintaining something called Zope 3 and it doesn't know whether it's an app server with a UI or a set of related packages that build on each other. I'm simply proposing we recognize that we also maintain this set of related 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 )
