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
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Reply via email to