Paul Everitt wrote: > On Dec 22, 2008, at 6:36 AM, Martin Aspeli wrote: > >> Chris (and Agendaless) is of course free to do whatever he wants with >> BFG. And as I've shown many times, I'm very supportive of the great >> work >> coming out of the Repoze project. >> >> However, if Repoze is aiming to bridge the gap between the mature Zope >> components and the WSGI-enabled world of other Python frameworks and >> tools, then we should at least debate when the pendulum swings further >> away from Zope. > > Repoze != BFG. Chris didn't change a single thing in Repoze itself.
Mmm... Chameleon is not in the repoze.* namespace, but it's in the Repoze repository, so if that's the definition of "Repoze" then he did. > People whose goal includes using existing Zope3 packages have to do > some work. Sure, they'll get a different flavor of adapters, but that > makes sense: they behave differently! Chris explained this, and you > don't want to discuss this, so I'll conclude that this discussion is > meta and not technical. It's absolutely about policy and roadmap, if that's what you mean by "meta". >>> Repoze != BFG >> This is certainly true. However, we've seen that a desire to do >> something in BFG (prune dependencies by replacing a core Zope package >> with a homespun version with tighter dependency control) had a knock- >> on > > Please list the cases where BFG has forced an inappropriate change on > Repoze. I think the fact that Chameleon now uses repoze.zcml may be. And my argument is that if you want to both use other parts of the Repoze stack that use the Zope 3 CA, and you want this minimal set of dependencies, then you're going to have to make the same change to all of those, which means that all other users of those packages have to live with the two ways of configuring components. That may be inappropriate. At least I think it deserves some serious consideration, not at least given how integration-oriented the Repoze stack tries to be. > Everybody wins, including non-Plone users. They count too. [wink] My point is not specific to Plone, even though that's obviously where I'm coming from. Anyone who wants to use existing Zope packages with BFG or Chameleon now have two means of configuring ZCA components in their stack. And this policy means that BFG (and maybe more of the Repoze stack, if it's a direct dependency of BFG) has now effectively written itself out of using *any* zope.* package bar the most basic ones that don't use ZCML in the zope:* namespace. That's a very small set of Zope packages. And potentially it's a growing list of packages that will need to be-implemented or forked for Repoze's needs. I guess I'm saying if I owned BFG, I'd make a different trade-off. I'm not telling you to do what I would do, though I think it's incorrect to say that "everybody wins" by this. > Remember, each time you want to say "transitive dependencies", you > should replace it with the more accurate "harmful side-effects". Mmm.... I'm not sure they're quite so harmful, although I agree that trusted adapters are a bit weird. Would they actually break a BFG app if used, or is it just that you haven't thought about using them? And is it worse to give people the possibility of (ab)using them in a BFG app than to fork Zope's configuration machinery? Maybe. Maybe not. > I think your vision that any plone.* package should work in BFG is the > flaw here. That's not the vision of BFG. plone.* packages are > designed, I believe, for sharing with other packages atop the Zope3 > application server. Sure. It was just an example, though, to illustrate that BFG apparently doesn't want almost anything of zope.* (bad grammar). That wasn't obvious to me. If that's the intention, then that's of course perfectly fine, although it makes BFG less attractive to me, personally, because it means I'm dependent on a smaller community of maintainers and users. Again, not a criticism, just an observation and a data point. But, as we've seen, this policy almost by necessity has to be pushed down into other repoze.* packages where they straddle the worlds of the ZCA and BFG. Since a lot of the Repoze project's effort is going into BFG these days, that seems like a logical conclusion. Again, this may make future and current repoze.* packages less attractive to Plone and other users who want more of zope.*. Again, not a criticism, just an observation. Although here is a slight criticism: Plone trunk is (probably) in the process of adopting Chameleon. I'd argue that repoze.zcml is not really an appropriate dependency for Plone, or at least one we'd rather avoid if we could. Yet here a BFG-driven decision meant that Plone now has to swallow this dependency, and there doesn't seem to be a lot of consideration that this could be a valid point of view. If Malthe's happy with this, I'll shut up and write some documentation to tell people that the bfg:adapter/utility/whatever directives are not to be used in Plone and hope no-one gets confused, or find some other compromise. I can't tell you what to do. But I can voice the concern, not at least because this point may not have been obvious to Chris (who possibly didn't know that Plone trunk has optional Chameleon support at this point). > I think, fundamentally, that's the issue. You want to sign Chris up > to fix Zope3. He wants to work on Repoze and BFG. You've got to admit it's a fine line to tread when you don't want to sign up to something as fundamental as Zope's core ZCML handlers, though. And the experience from Plone is that sometimes this is a costly policy in the long run. It's a piece of advice. Take it or leave it. >> I certainly feel for Chris when he says he's worried about stop energy >> in Zope 3 land. There's a fair amount of that. But things do get done, >> when there's a will. Jim is a huge advocate of untangling >> dependencies. > > It has been explained to you that this is more than a mere packaging > discussion. Possibly you disagree, as you still paint it as > "untangling dependencies". If Zope had a cleaner dependency structure that made things like zope.security and trusted adapters optional, repoze.zcml wouldn't be needed, right? > Thus, since you have the "will", and since Chris has already done the > "way", I recommend that you take repoze.zcml back to the Zope 3 > community and get their read on it. Chris has scratched half of your > itch. Shouldn't you walk the walk and do your half? I'll do my best to contribute constructively. I'm probably not going to bother with this debate any more, though, as I've said what I wanted to say and it's getting a bit silly and lengthy. > repoze.zcml is a symptom that not everybody has the same needs. > Grok's configuration system wasn't incepted in the Zope 3 stack. It > was done under its own flag, and projects that wanted it, took upon > themselves to evaluate it and integrate it. Nobody demanded that the > Grok people do their reformation inside Zope3 itself. Yep, but Grok's model is sufficiently different to be less confusing. And Grok hasn't talked itself out of using the majority of zope.* packages due to this configuration system. We're comparing apples and oranges, though, since Grok is most definitely built atop Zope 3. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book _______________________________________________ Repoze-dev mailing list Repozefirstname.lastname@example.org http://lists.repoze.org/listinfo/repoze-dev