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. >> Everybody wins. > > I'm not quite sure about this. Anyone who wants to use traditional > Zope > packages that are configured using the standard zope ZCML stuff in a > BFG > application now has to contend with two methods of configuration that > look identical but for an xmlns line at the top of the ZCML file, but > are implemented in different places. That sounds like a recipe for > confusion (especially considering that there is a reasonable amount of > documentation and doctests out there that refer to the "old" way). It > also sounds really hard to debug if ever there's a conflict between > the > two types of handlers. Some people want to use BFG but aren't after "fidelity to the Zope3 megaframework". These people should not pay a tax. Remember, Zope3 assumes a ZODB. BFG doesn't even include ZODB. 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. People who want to use ToscaWidgets (like me) have to do some work, too. That's part of the Zen of BFG: it leaves out a LOT. You only pay for what you eat, and we don't want to pay for trusted adapters. "Only pay for what you eat" isn't your goal. It's ok for new projects to start up and tackle fresh ideas and go in new directions. >> 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. > effect on transitive dependencies in the Repoze world, which in turn > impacts other users of those packages. The change in Chameleon meant > that Repoze lost a few dependencies it didn't need, and Plone gained a > few (or at least one) it didn't need. The change meant Chameleon lost dependencies and *huge swaths of side- effect-ful, harmful* policy that it didn't need. Chameleon doesn't exist solely for Plone, I believe. Chameleon users are now the beneficiary of Chris's work to make a smaller, less side- effect-ful Chameleon. This served Chameleon's purpose, which is to be bigger than Plone/Zope. He also did extra work to make it easy to sign up for the Zope assumptions. Everybody wins, including non-Plone users. They count too. [wink] > This is what I meant about BFG becoming a monolith: not that it's not > built from reusable packages, but rather that if you want to control > the > transitive dependencies like this, you're going to have to re- > implement Remember, each time you want to say "transitive dependencies", you should replace it with the more accurate "harmful side-effects". > any part of zope.* or plone.* or other users of the traditional ZCML > way > of configuring the CA, with repoze.* equivalents that are not thus > polluted. True. But so what? Those packages presume a pile of assumptions that shouldn't be shoved down the throat of every possible BFG user. BFG doesn't provide the packages they assume, so they wouldn't work anyway. It's up to the person whose goals include plone.supermodel to sign up for the side effects. 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. BFG is not atop the Zope3 application server. Perhaps that part is unclear. We're like most people: when it is convenient to grab something, BFG will. If the pain is too high, then no. Rational behavior. > If you want to pull in, say, plone.supermodel (a "pure Zope 3" package > that should be re-usable and may be useful to BFG if it ever wants to BFG would never, ever, never have a goal of "serialize Zope 3 schemas". It doesn't include Zope 3 schemas. It doesn't include the *concept* of schemas!! However, some BFG user might want plone.supermodel. Some Pylons user might want plone.supermodel. In either case, the integration task falls on the integrator, not the destination framework. The integrator is responsible for including the packages that supermodel wants, which includes Zope3-style trusted adapters. > serialise Zope 3 schema interfaces to/from an XML representation) > well, > it uses zope:* ZCML directives. Are you going to fork > plone.supermodel? > Are you going to re-implement your own version? Are you going to > advocate that it too moves to repoze.zcml? None of those options sound > particularly attractive. No, the user is going to add a line to their package and be off the the races. An eminently fair tradeoff. Sure, it would be nicer if Zope 2, Zope 3, Grok, and Repoze could all magically have the same needs. Sometimes they do, sometimes they don't. When it is easy to share, they share. When it is hard to share, the people that care a lot about that fix the underlying problems. I think, fundamentally, that's the issue. You want to sign Chris up to fix Zope3. He wants to work on Repoze and BFG. > 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". 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? > As are the Grok people. As are the Plone people. Repoze and Grok are > where the innovation in the Zope world is happening right now, so I > think they have a license to push things through. Instead of > repoze.zcml, perhaps we could have a branch of the relevant zope.* > package? We could then merge that later. > > > repoze.zcml is a symptom that an improvement is needed further down > the 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. I think that worked well for Grok. Sounds like what Chris is doing. Everybody wins. --Paul _______________________________________________ Repoze-dev mailing list Repozeemail@example.com http://lists.repoze.org/listinfo/repoze-dev