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 Design"http://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 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...
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...
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...
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. 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? 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? 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. 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. 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...
Summary: there isn't really a problem, because BFG is not Repoze. People that want the side-effects in BFG can still get them. Everybody wins. On Dec 21, 2008, at 6:06 AM, Martin Aspeli wrote: > I realise Plone isn't your main concern here, but this is basically > what's going to happen to anyone who use lower level Repoze components > that use this means of configuration in a non-BFG context (or at least > in conjunction with more general Zope stuff). I don't see why this is true. Chris changed BFG, not Repoze. Chameleon changed, and if Plone does or doesn't use Chameleon, Chameleon-in-Plone simply needs to internally do something tiny. It already internally imposed lxml as a requirement. This change is *tiny* compared libxml2+lxml+Cython. I'm not sure it is true that use of any "lower level Repoze components" has changed. Since this seems to be the heart of your point, can you illustrate where this is true? BFG is not Repoze. BFG certainly isn't trying to be Zope, and thus, shouldn't sign up for the mound of policies that Chris did the analysis on. You didn't comment on his writeup, though: do you concur with his point, that the package list is laden with (harmful for non- Zope) policy? Frankly, the "more of an island than it already is" lead-in comes across as an ill-informed insult. BFG starts with easy_install, then virtualenv, then Paste, then WSGI, then WebOb, before you even see BFG. It ships with Chameleon: when do you suppose Zope 2/3 will replace ZPT with Chameleon? BFG doesn't even *include* ZODB, much less, require that you have a root before you can write your non-ZODB application. I think we're working harder to hang out with other Python web technologies than anybody else in the Zope world, by far. You have a weird definition of "island". > I think that's a shame, because it's an argument against adopting > Repoze > components in other frameworks. Plone already has far too many > almost-identical-but-not-quite ways of configuring things and we're > trying hard to consolidate. We don't have to use repoze.zcml ourselves > (and we almost certainly won't), but as people try to understand the > stack, it's another thing they have to be aware of. As we start using > more Repoze components (trunk already pulls in siz repoze eggs) it's > something we may start bumping up against higher up in the stack than > the template engine. > > From experience, it's not unlikely that people will then start copying > the approach used by Chameleon and then get rather confused when they > realise that can mean two subtly different things > depending Yes, because the policies in can be harmful when used outside of Zope. Chris is doing the responsible thing: not giving false advertising that this is the same set of assumptions as Zope. Hopefully you're not arguing that BFG should, for example, adopt the idea of non-trusted code, just to make sure we use the same ZCML directives? > on an xmlns line at the top of their configure.zcml. > > I'm not saying what you've done was bad for repoze.bfg, but at least > be > cognisant that repoze.bfg and by extension, possibly the wider repoze That seems like a false leap. --Paul > stack, is starting to smell more like a fork of "Zope" (or at least a > particular combination of various Zope components), that's going to > make > the attractive bits of the stack harder to swallow for other users > of Zope. ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] bfg zcml directives...
repoze.bfg has a core concept of "pay only for what you eat", so, as Paul put it
(with a 30 point word no less!), "fidelity" with Zope is not a goal; where we
don't need things that Zope offers, we explicitly get rid of them. This helps
keep things honest and understandable, particularly in places where concepts
overlap ("why do I need zope.security when BFG has its own security? why do i
need zope.traversing when BFG does its own traversal? why do i need
zope.publisher when BFG has its own publisher?").
You understand this goal, as below you argue for it in the context of Plone. I
am sorry it needs to be one way or the other currently (either bfg gains four
dependencies and directive attributes that are actively harmful or Plone gains
one dependency), but that's how it is until we can figure out a way to get
everybody what they want. But one thing won't happen: bfg is not going to live
with four inappropriate dependencies forever to service a goal of fidelity. So
we can either figure out a single way that everyone wins, or we leave it as is.
That's the set of options you lobbied for me to choose from in your original
email, so I present them back to you, where that decision is yours to make
instead of mine.
That said, to the extent that we can push functionality down into Zope bits and
help detangle dependencies in the course of doing the cleanup, we'll definitely
do so. But if cleanup is vetoed, we are going to fix it one way or another.
- C
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 realise Plone isn't your main concern here, but this is basically
> what's going to happen to anyone who use lower level Repoze components
> that use this means of configuration in a non-BFG context (or at least
> in conjunction with more general Zope stuff).
>
> I think that's a shame, because it's an argument against adopting Repoze
> components in other frameworks. Plone already has far too many
> almost-identical-but-not-quite ways of configuring things and we're
> trying hard to consolidate. We don't have to use repoze.zcml ourselves
> (and we almost certainly won't), but as people try to understand the
> stack, it's another thing they have to be aware of. As we start using
> more Repoze components (trunk already pulls in siz repoze eggs) it's
> something we may start bumping up against higher up in the stack than
> the template engine.
>
> From experience, it's not unlikely that people will then start copying
> the approach used by Chameleon and then get rather confused when they
> realise that can mean two subtly different things depending
> on an xmlns line at the top of their configure.zcml.
>
> I'm not saying what you've done was bad for repoze.bfg, but at least be
> cognisant that repoze.bfg and by extension, possibly the wider repoze
> stack, is starting to smell more like a fork of "Zope" (or at least a
> particular combination of various Zope components), that's going to make
> the attractive bits of the stack harder to swallow for other users of Zope.
>
> Martin
>
___
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...
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. > > 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. 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. - C ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] bfg zcml directives...
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 ;) >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. 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. Hanno ___ 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 It 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...
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 realise Plone isn't your main concern here, but this is basically what's going to happen to anyone who use lower level Repoze components that use this means of configuration in a non-BFG context (or at least in conjunction with more general Zope stuff). I think that's a shame, because it's an argument against adopting Repoze components in other frameworks. Plone already has far too many almost-identical-but-not-quite ways of configuring things and we're trying hard to consolidate. We don't have to use repoze.zcml ourselves (and we almost certainly won't), but as people try to understand the stack, it's another thing they have to be aware of. As we start using more Repoze components (trunk already pulls in siz repoze eggs) it's something we may start bumping up against higher up in the stack than the template engine. From experience, it's not unlikely that people will then start copying the approach used by Chameleon and then get rather confused when they realise that can mean two subtly different things depending on an xmlns line at the top of their configure.zcml. I'm not saying what you've done was bad for repoze.bfg, but at least be cognisant that repoze.bfg and by extension, possibly the wider repoze stack, is starting to smell more like a fork of "Zope" (or at least a particular combination of various Zope components), that's going to make the attractive bits of the stack harder to swallow for other users of Zope. 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
