Re: [Repoze-dev] bfg zcml directives...
2008/12/22 Martin Aspeli optil...@gmx.net: 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. Chameleon no longer depends on repoze.zcml, or zope.configuration for that matter. It does still attempt to look up translators as Zope components, but it comes with a default configuration implemented as a module-global Python dictionary. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] bfg zcml directives...
Mmmm... I didn't mean for this to get quite so emotional. :) 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. 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. 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 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. 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 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. 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 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. 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. 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 stack. In the Plone world, we've learned the hard way that rolling your own to avoid having to push something deeper into the stack is a costly strategy in the long run. Paul should certainly know this. :) It may be that Repoze should take a bit more pain now, in the form of writing a proposal and putting up with some flak or politicking, to save having to maintain a growing amount of custom code later. Or not. But at least let's not give up before we've tried. Cheers, 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 Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] bfg zcml directives...
Tres Seaver wrote: Note that one change I would make to the docs is to make using the 'bfg' namespace *not* the default in the examples; marking each non-Zope directive with 'bfg:' (in the examples, not necessarily in a real-world config) would remind people, this is not your father's Oldzopemobile, as is true already for 'bfg:view'. +1 Martin ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] bfg zcml directives...
Martin Aspeli wrote: Wichert Akkerman wrote: Previously Martin Aspeli wrote: 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 serialise Zope 3 schema interfaces to/from an XML representation) well, it uses zope:* ZCML directives. Are you going to fork plone.supermodel? I would be very tempted at least. Or decide to not use supermodel. Which would mean that the BFG-intersecting parts of the repoze stack would be a fork or re-implementation of all Zope stuff that was interesting to it. I don't think that's a sustainable way forward. Or at least, then repoze should stop billing itself as the maturity of Zope now with the flexibility of the WSGI future. But I don't think that's what Paul or Chris would want. :) BFG is a bit sideways to the goals of the Repoze stack (which is actually what that tag line refers to, rather than BFG). If I had it to do all over again, repoze.bfg would be named just BFG (without the repoze). I doubt it's possible to make this change now, apologies, folks will just have to understand. Please try to make the mental jump required to separate WSGI middleware and libraries labeled repoze (like repoze.errorlog, repoze.tm, repoze.squeeze, repoze.monty, etc.) and BFG itself. Conflation of BFG with the rest of the repoze stack that is explicitly meant to be middleware and libraries is a mistake. - C ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] bfg zcml directives...
On Dec 22, 2008, at 1:06 PM, Martin Aspeli wrote: Wichert Akkerman wrote: Previously Martin Aspeli wrote: 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 serialise Zope 3 schema interfaces to/from an XML representation) well, it uses zope:* ZCML directives. Are you going to fork plone.supermodel? I would be very tempted at least. Or decide to not use supermodel. Which would mean that the BFG-intersecting parts of the repoze stack would be a fork or re-implementation of all Zope stuff that was interesting to it. I don't think that's a sustainable way forward. Or at least, then repoze should stop billing itself as the maturity of Zope now with the flexibility of the WSGI future. Demonstrably false. Please list the Repoze components, particularly the ones Plone is using, that were affected by this change. --Paul ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] bfg zcml directives...
Martin Aspeli wrote: 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. OK, sue me, not my last comment. ;-) Much of the argument here revolves around the fact that chameleon.core and chameleon.zpt both *contain* ZCML. Maybe neither should, given that they are meant to be libraries useful outside of any particular framework. If they did not contain any ZCML, they would drop their dependency on zope.configuration, and glue packages would need pick up the slack to configure them however they chose. Maybe we can ask Malthe to make ZCML-based configuration of Chameleon a documentation task rather than a software task. That might be a far easier thing to do than trying to reengineer the directives in zope.component, and it would solve the problem of inappropriate dependencies in both directions. - C ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] bfg zcml directives...
Paul Everitt wrote: On Dec 22, 2008, at 1:06 PM, Martin Aspeli wrote: Wichert Akkerman wrote: Previously Martin Aspeli wrote: 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 serialise Zope 3 schema interfaces to/from an XML representation) well, it uses zope:* ZCML directives. Are you going to fork plone.supermodel? I would be very tempted at least. Or decide to not use supermodel. Which would mean that the BFG-intersecting parts of the repoze stack would be a fork or re-implementation of all Zope stuff that was interesting to it. I don't think that's a sustainable way forward. Or at least, then repoze should stop billing itself as the maturity of Zope now with the flexibility of the WSGI future. Demonstrably false. Please list the Repoze components, particularly the ones Plone is using, that were affected by this change. Paul, I'm not sure if you're just being facetious now... I've listed it in every email in this thread, and it's getting a bit irritating having to repeat it. Plone uses Chameleon. Chameleon is in the Repoze repository. Chris changed Chameleon. Plone is affected. If there are parallels with Chameleon (things that BFG want to use, that use the ZCA and depend on Zope 3's standard ZCML handling) then those will necessarily need to follow the same path. This may make those packages less attractive re-use in Zope 3-dependent projects and I think we should at least acknowledge that. Plone is starting to embrace the Repoze stack in a big way. I don't think it's unreasonable of us to want to investigate the motives behind the people working on Repoze to understand how the Repoze development roadmap may affect Plone in the future. So, here's what I've learned, and correct me if I'm wrong: - BFG does not intend to be part of the Repoze stack quite in the way that Repoze is trying to bridge the Zope and WSGI/Python worlds. This wasn't clear to me, but then I've never claimed to be deep into BFG either. - BFG has little interest in re-using the various zope.* packages beyond the very core zope.interface and zope.component. - Where BFG does want such a package, it may need to fork or re-implement it to avoid a transitive dependency on zope.security and friends. This is a trade-off the BFG developers are willing to make for the sake of a smaller dependency graph and less code in the stack that doesn't work well with BFG if used. - There may be a conflict of interest where a BFG dependency that uses the ZCA is re-used outside BFG, because of the different ways to configure components. This is something we'll have to manage, I guess. I am happy to leave it at that. It doesn't make me think that using repoze.zope2 and related middleware in Plone is a bad idea. I think the Chameleon change is a bit troubling, but Chris' suggestion to push the configuration further up in the stack, making it a documentation issue, is a good one IMHO. 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 Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] bfg zcml directives...
Previously Martin Aspeli wrote: Wichert Akkerman wrote: Previously Martin Aspeli wrote: 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 serialise Zope 3 schema interfaces to/from an XML representation) well, it uses zope:* ZCML directives. Are you going to fork plone.supermodel? I would be very tempted at least. Or decide to not use supermodel. Which would mean that the BFG-intersecting parts of the repoze stack would be a fork or re-implementation of all Zope stuff that was interesting to it. I don't see that. That is just my personal opinion and might not hold for anyone else here. Zope packages have a tendency to pull in half the zope world and introduce a lot of zcml and security that you almost never want in a non-zope environment. Unfortunately there appears to be little will in zope-dev to actively change that. That's a shame, since it it drastically reducing the chance of zope technology being accepted and used by others. If reimplementing something is easy to do (which is generally true considering we all have Zope's source) and allows you to drop all that extra baggage that - why not? Wichert. -- Wichert Akkerman wich...@wiggy.netIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] bfg zcml directives...
Wichert Akkerman wrote: If reimplementing something is easy to do (which is generally true considering we all have Zope's source) and allows you to drop all that extra baggage that - why not? Because you have to maintain it forever. Of course, you may not mind doing that - it'll be a case-by-case thing. 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 Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] bfg zcml directives...
Previously Martin Aspeli wrote: Chris McDonough wrote: That package is now done... http://static.repoze.org/zcmldocs and http://pypi.python.org/pypi/repoze.zcml/0.1 I've adjusted the trunk of bfg and the trunk of chameleon.zpt to use ZCML declaration implementations from this rather than using the stock implementations from zope.component. Given that Plone also uses chameleon.zpt (via five.pt) this means that, if I understand correctly, Plone now gains this dependency, and part of the Plone stack uses what will seem to most people like an arbitrary, almost-identical-but-not-quite way of configuring components that's different to what the rest of the stack uses. I'm not sure that is true: people can still use the standard zope zcml directorives instead of the repoze.zcml alternatives and everything will work normally. The only downside is that chameleon.zpt will pull in a few extra packages, but you yourself have argued that that should not bother people. Wichert. -- Wichert Akkerman wich...@wiggy.netIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] bfg zcml directives...
Wichert Akkerman wrote: Previously Martin Aspeli wrote: Chris McDonough wrote: That package is now done... http://static.repoze.org/zcmldocs and http://pypi.python.org/pypi/repoze.zcml/0.1 I've adjusted the trunk of bfg and the trunk of chameleon.zpt to use ZCML declaration implementations from this rather than using the stock implementations from zope.component. Given that Plone also uses chameleon.zpt (via five.pt) this means that, if I understand correctly, Plone now gains this dependency, and part of the Plone stack uses what will seem to most people like an arbitrary, almost-identical-but-not-quite way of configuring components that's different to what the rest of the stack uses. I'm not sure that is true: people can still use the standard zope zcml directorives instead of the repoze.zcml alternatives and everything will work normally. The only downside is that chameleon.zpt will pull in a few extra packages, but you yourself have argued that that should not bother people. +1 - C ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] bfg zcml directives...
Martin Aspeli wrote: Paul Everitt wrote: That seems like a false leap. I freely admit to using hyperbole in my original email to draw out a debate. :-) It does bother me a little, though, that the fix seems to be to fork/re-implement rather than to try and push something downstream. No-one in Zope is disagreeing that the dependencies should be untangled. Few people seem to have the time and impetus to do something about it. When BFG does, then it'd be great if that effort could benefit everyone. If repoze.zcml was named zope.zcml (or zope.zcmlthatdoesless or whatever), would that help? The only other option would be to convince the test what you fly, fly what you test crowd that we really do need permission/trusted-less ZCML directives in the core, and that they'll need to undergo some pain (and cease contributing stop energy to the discussion) to allow us to get what we need. I've never been very successful at that, so I just avoid doing it. My specific reaction, by the way, was not to BFG, but to Chameleon. Does chameleon.zpt belong to BFG? This wasn't my impression. And if so, does Plone need to be wary of adopting it, for fear of it growing a lot closer to a BFG philosophy that's not necessarily going to be compatible with Plone's architectural vision going forward? Chameleon belongs to those who help maintain it, IMO. Primarily this means it belongs to Malthe, who has written 99% of its code. I checked into it yesterday a dependency on repoze.zcml. I did not get permission to do so from Malthe. But unless I have a very poor sense of judgment, I suspect Malthe will cheer about shedding four dependencies. As far as architectural vision, Plone makes a lot of sacrifices for backwards compatibility, all of which are reasonable in the context it's developed in. They make no sense, however, to other projects, and Plone can't expect other folks to live with them forever because it has chosen to. But if change *is* desired, there is some responsibility incumbent upon Plone devs to get with the program here and bring some pressure to bear; you've seen that Zope 3 development is currently landlocked, right? Every time somebody brings up some moderate change on zope-dev, it's more or less immediately shot down by the folks that don't want to think about it. What other choice do we have but to fork? What about the other repoze.* packages? Which ones are going to inhibit this parallel universe where things are done almost like other parts of Zope, but not quite? After ZCML, what's next? The good old slippery slope argument. But admittedly there's some truth to it here in the context of BFG... for BFG, what's next is whatever we goddamn well please. ;-) (This doesn't really extend to other repoze packages, FTR, just BFG). If we can help Zope in the meantime, great. There is an obvious risk here, as demonstrated by the chameleon.zpt case, that the desire to prune transitive dependencies means BFG either ends up being more monolithic (i.e. owning its own, tightly controlled, minimal versions of everything) or pushing alternate methods for things like configuration into lower level packages, because dependencies can't be kept to an absolute minimum otherwise. Any package the Zope world would develop to solve this problem would smell almost exactly like the one implemented in repoze.zcml. So there's a blueprint. Let's figure out how to put it in the core, or not. Re-use always carries a risk of getting more than you bargained for, because the author of the original package may not have intended it to be re-used in exactly the way you need. But sorry about the island gripe - I'm very grateful for the work repoze is doing to play well in Python land, and, as you know, I'm a strong advocate of Plone and Zope riding that bandwagon. I just worry that sometimes this may mean leaving the rest of Zope behind, rather than work to bring it along. Taking action is the best way to move things along. It got you interested, didn't it? ;-) - C ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] bfg zcml directives...
On Dec 21, 2008, at 9:31 AM, Chris McDonough wrote: But one thing won't happen: bfg is not going to live with four inappropriate dependencies forever to service a goal of fidelity. Repoze is the place where we co-habitate with the goals of other projects, such as Zope and Plone. BFG, though, is where we make something that is more fun than frustration, defining the goals and limits to serve the purpose of BFG. Thus, +1M on Chris's point. People that want the fidelity of Zope already have other choices. Hell, Zope itself gives them two very different choices, and Grok is a third. People who want to enjoy other Python web stuff as part of the core, in combination with the fun part of Zope, and strive for fun and minimalism, now have a place to hang out. People that don't share that goal, or have the goal of Zope fidelity, are well-served elsewhere. BFG != Zope, by the original motivation of its creation. --Paul ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] bfg zcml directives...
On Dec 21, 2008, at 11:36 AM, Martin Aspeli wrote: Paul Everitt wrote: That seems like a false leap. I freely admit to using hyperbole in my original email to draw out a debate. :-) It does bother me a little, though, that the fix seems to be to fork/re-implement rather than to try and push something downstream. No-one in Zope is disagreeing that the dependencies should be untangled. Few people seem to have the time and impetus to do something about it. When BFG does, then it'd be great if that effort could benefit everyone. Chris provided an analysis showing that this is more than packaging. There are policy decisions involved. Could you comment on his writeup about the policies and side effects? Should people that want to use Zope-style components, also be forced to digest trusted adapters? Or, is someone brave enough to convince the Zope world to either ditch that idea? Or, shepherd a proposal to make it parameterizable? It isn't their itch, so they won't implement the proposal. Instead, you'll be asking the people that *don't* want trusted adapters, to do the work to paramaterize it. Thus, this is harder than just untangling dependencies, IMO. My specific reaction, by the way, was not to BFG, but to Chameleon. Does chameleon.zpt belong to BFG? This wasn't my impression. And if so, does Plone need to be wary of adopting it, for fear of it growing a lot closer to a BFG philosophy that's not necessarily going to be compatible with Plone's architectural vision going forward? I presume that Chameleon belongs to Malthe et al. I doubt a change would be made that he disagreed with. But I'll invert the question: does Chameleon belong to Zope? I believe Chameleon aspires to life beyond the Zope island. If so, then it is a Great Thing to shed those rather harmful side effects, while enabling a *TRIVIAL* way to sign back up for them in Zopeland. Everybody wins. What about the other repoze.* packages? Which ones are going to inhibit Yes, you made this assertion, and I'm asking you to demonstrate the facts behind that assertion. Are you claiming that repoze.zope2 has changed? repoze.retry? repoze.tm? repoze.who? this parallel universe where things are done almost like other parts of Zope, but not quite? After ZCML, what's next? Hopefully, lots of stuff is next, but for BFG. Repoze is the place of co-habitation with the goals of fidelity. There is an obvious risk here, as demonstrated by the chameleon.zpt case, that the desire to prune transitive dependencies means BFG either ends up being more monolithic (i.e. owning its own, tightly controlled, Calling bfg a monolith is, like calling it an island, just plain silly. BFG is the opposite of a monolith, as I demonstrated in my previous mail. Also, BFG does not have the goal of fixing Zope's tightly-controlled monolith. Again, Chris spent the time to show that this is more than pruning transitive dependencies. This is pruning harmful (to non-Zope), side- effect-ful (to non-Zope) policies that are part of the goal in Zope. minimal versions of everything) or pushing alternate methods for things like configuration into lower level packages, because dependencies can't be kept to an absolute minimum otherwise. Re-use always carries a risk of getting more than you bargained for, because the author of the original package may not have intended it to be re-used in exactly the way you need. But sorry about the island gripe - I'm very grateful for the work repoze is doing to play well in Python land, and, as you know, I'm a strong advocate of Plone and Zope riding that bandwagon. I just worry that sometimes this may mean leaving the rest of Zope behind, rather than work to bring it along. Chris has worked hard *in Repoze*, harder than just about anybody else, to bridge the gap and bring it along. He's asking that BFG be his own place, where he can build just the thing he wants, and leave out the parts he doesn't want. People don't have to use it if that isn't their goal. --Paul 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 Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] bfg zcml directives...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris McDonough wrote:
Hanno Schlichting wrote:
Chris McDonough wrote:
Maybe there's some potential to create a set of core ZCML registration
handlers
for utility, adapter, subscriber, and interace that are not actually part of
BFG, but on which BFG and other non-Zope apps could depend. I suspect this
is
the only realistic way to go forward: I don't think it's reasonable to tell
the
people who have Zope apps in production which use these declarations that
they
won't be able to use untrusted code or permission declarations, or the
global
registry.
Should this discussion happen on the zope-dev list or is that too
hostile these days ;)
I'd be happy if this discussion migrated to zope-dev.
From my point of view, configuration of components is an area where
every Zope-based project takes a different approach to right now:
- Zope3 has its own handlers tied in deeply into the rest of the application
- Zope2 has its own handlers (in Products.Five) which are highly
dependent on the rest of the application
- Grok uses a different approach and has written its own configuration
approach
- Plone might want to adopt a Grok-style approach and will need to use
yet another kind of five.grok or similar handlers
- repoze.bfg now gained its own implementation of the core ZCML handlers
What all projects have in common, is the abstract concept behind those
handlers and the dependency on zope.component and zope.interface. We all
have interfaces, utilities and adapters.
What is different is the exact way these concepts need to be configured
to fit into the framework. One problematic bit is that depending on the
framework the configured result actually has different semantics at some
points as well.
What can we do about this?
Every framework makes it more obvious that they have different
implementations of the same concepts and provide them in a different
namespace / approach? That results in integration packages to be
required to be able to use a package from one framework in a different one.
No: just *don't use the directives*. Reusing policy-laden
configuration is an anti-goal, compared to re-using software.
We all claim to be in the same namespace and let the result of the
configuration be dependent on the framework it is used in? That is more
convenient to (re-) use but has the risk of hiding the semantic differences.
- -100 to that option. This is why we have namespaces in the first place.
It just doesn't seem feasible to break backwards compatibility to make the
core directives do less all the time.
It'd work to add knobs to the core directive packages that let it detect
whether
the directives use more advanced features like trusted and permission,
but
it might make the ZCA code a little convoluted. I suspect that floating that
idea on zope-dev would be the only way to tell. I wonder if anyone has enough
context using the ZCA outside of Zope for the idea itself to make much sense
to
them.
This is why stripping dependencies is hard: the dependencies don't hurt
the folks who want the policies served by them, while stripping them
out, and parameterizing the code which currently hardwires the policies,
makes those same developers' lives harder (now they have to add the
dependncies to their own code) and their code more convoluted. We can't
even get them to agree to simple things like stripping out *test*
dependencies from the main 'install_requires'; what makes you think
they would be willing to move the Zope{2,3}-only stuff out?
Note that one change I would make to the docs is to make using the 'bfg'
namespace *not* the default in the examples; marking each non-Zope
directive with 'bfg:' (in the examples, not necessarily in a real-world
config) would remind people, this is not your father's Oldzopemobile,
as is true already for 'bfg:view'.
Tres.
- --
===
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJTxqK+gerLs4ltQ4RAt3VAJsEcZgz/ubvN85EYSptdtEx59H+cgCeJYru
IQF/f0utHYPYb/61VKlheP4=
=pbDp
-END PGP SIGNATURE-
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] bfg zcml directives...
On Dec 20, 2008, at 2:12 PM, Chris McDonough wrote: Paul Everitt wrote: On Dec 20, 2008, at 1:59 PM, Chris McDonough wrote: As a result of messing around with the ZCA + ZCML outside the context of Zope, I've found that it may be possible to significantly reduce the number of egg dependencies of BFG by replacing the code that allows the following ZCML directives to work: - utility - adapter - interface - subscriber As such, I'm thinking of ditching the handlers written zope namespace for these directives in favor of handler written in the bfg namespace. So, for Interesting idea. I suppose the decorator syntax wouldn't change, but the machinery behind it would. zope.configuration doesn't provide any decorator syntax, but if you mean the Sorry, I meant repoze.bfg.convention. I believe that, under the hood, it's doing the same configuration work as ZCML. ZCML syntax, yes, exactly; it wouldn't change for the utility or adapter directives. One fallout change would be that instead of: bfg:view for=.models.MyModel view=.views.my_view / The view directive would be just: view for=.models.MyModel view=.views.my_view / (because the bfg XML namespace would be the default). example, rather than doing: configure xmlns=http://namespaces.zope.org/zope; utility provides=.interfaces.IFoo factory=.foo.Foo/ /configure You would instead do: configure xmlns=http://namespaces.repoze.org/bfg; utility provides=.interfaces.IFoo factory=.foo.Foo/ /configure The down side of this is that it would mean that existing applications that used ZCML would need to change their ZCML, or they'd at least need to declare zope.security as an install_requires dependency and do a manual include of the zope.component ZCML: include package=zope.component file=meta.zcml / I think it's pretty reasonable to make that requirement in order to get that gain. Meaning, apps would still work with a one-line setup.py change and a line of ZCML. Right. Creating parallel adapter, utility and subscriber handlers is really how I should have started things out, but I didn't, and given that there are people using the system in the wild that this would cause problems for in a new release, I wanted to ask for comments. Here are the dependencies we might be able to shed by doing this: zope.location-3.4.0-py2.4.egg zope.publisher-3.5.4-py2.4.egg zope.security-3.5.2-py2.4-macosx-10.5-i386.egg zope.traversing-3.5.0a4-py2.4.egg zope.i18n-3.6.0-py2.4.egg pytz-2008i-py2.4.egg My personal opinion is that doing this is worth it for the long term. None of these packages actually *do* anything for bfg apps, they're just required to satisfy dependencies of features we can't use. For applications that do a Zope-ish architecture (ZODB, security, etc.), how many of those packages would they need to pull in manually? Security is not a feature provided by any Zope package in a BFG app; ZODB requires whatever its setup.py says it requires. In terms of the Zope-ish applications we (Agendaless) are developing under BFG, no changes would need to be made to any setup.py install_requires. Right, I meant the latter. For people that are writing BFG applications that smell like Zope (e.g. KARL), how many of those packages would still be used, thus lessening the win in that case? --Paul ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
