Re: [Zope-dev] Stripping down zope.component
Tres Seaver wrote: [snip] I'd say leave the extra shim in place for the time being. We can then see about getting rid of that at some point. > In any package where I create a backward incompatibility, I will > certainly document it clearly, with instructions on how to update > dependent packages. Putting the canonical docs in the package is an > absolute necessity for reuse of the package outside any larger package > set, anyway. Agreed about that. Concerning a master list of changes. Let's ignore the concept of lockstep releases for the time being in this discussion. We can easily decouple this from the discussion about a list of major changes to various zope packages. I'd still like there to be a master list marks big changes that people need to be aware of when they upgrade their packages to newer versions. If they're going to make their own package lists, they can get an overview of what to watch out for. And us people who maintain lists of such packages that get release numbers can also look out for those. This isn't a list by version but just a list maintained by date, or per change. Now that I think about it, we can turn it around and aggregate the existing CHANGES.txt as news somehow. Perhaps some way to turn them into Atom feeds; a script would then be simple enough to write to aggregate all non-bugfix releases. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Stripping down zope.component
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: > Hi there, > > Tres Seaver wrote: > [snip] >> Actually, we don't need an upgrade path. We can just leave a >> 'meta.zcml' in zope.component which the new locations. That >> file will be *inert*, and doesn't therefore need testing, because none >> of the directive implementations will be present. >> >> Over time, people can shift to including the new meta.zcml at their >> leisure. We can leave the redirecting meta.zcml in zope.component >> *forever*, if need be. > > It's not just the meta.zcml story, where I can agree we could leave > something in place, but it's the dependencies in setup.py, right? Right. Dropping any dependency on zope.configuration, zope.security etc. *will* happen. The folks affected by such a change will be those who rely on the current transitive dependency graph to pull in those pacakges: they will need to update their versions.cfg / setup.py, etc. in order to pick up the new version of zope.component. See below for the documentation required. > If the implementation of the directives lives in zope.componentzcml, any > codebase that loads any ZCML at all (in its tests especially) is very > likely to need zope.componentzcml besides zope.component. Or am I > missing something here? It needs to have it importable, yes (so that the redirected meta.zcml works). Come to think of it, we could even leave the extras in place for BBB, since anybody who has been relying on the transitive graph has to be depending on 'zope.component[zcml]' already, right? I don't have a problem with leaving it in place as a pure dependecy shim. > [snip] >>> Anyway, this upgrade path needs to be spelled out clearly in the >>> zope.component CHANGES.txt pointing people in the right direction. We >>> also need to spell it out in this document: >>> >>> http://svn.zope.org/zope3docs/source/migration/34to35.rst >> Maintaining that document is out of scope for me. ;) > > If my above story about the dependencies is right, it is necessary to > remark this in a central place. We do have framework-wide policies in > place, and explaining to people how to unbreak their code in a single > place they can look should be one of them. We do after all have people > who use a whole bunch of these libraries at the same time. But if you > can write it clearly in the CHANGES.txt and tell me, I'll add it to that > document if you can't be bothered. It isn't that I can't be bothered: I'm don't want to reinforce the idea of a new monolithic release labeled "3.5" to which people will upgrade from the current "3.4" in lockstep. Not only do I not want to *use* such a monolith; I'm convinced that trying to maintain it can impede (and has impeded) develpoment of the actual bits which make it up. I won't do anything active to defeat your efforts in that direction, but I don't want to help on that part. In any package where I create a backward incompatibility, I will certainly document it clearly, with instructions on how to update dependent packages. Putting the canonical docs in the package is an absolute necessity for reuse of the package outside any larger package set, anyway. 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 iD8DBQFJsUeQ+gerLs4ltQ4RAihbAJ4gwRemxOz7/CT/wQUpkLEd++EQFgCfUHm6 0i2xCkbvckMB/pp59ezpCKk= =n7Fv -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Stripping down zope.component
Hi there, Tres Seaver wrote: [snip] > Actually, we don't need an upgrade path. We can just leave a > 'meta.zcml' in zope.component which the new locations. That > file will be *inert*, and doesn't therefore need testing, because none > of the directive implementations will be present. > > Over time, people can shift to including the new meta.zcml at their > leisure. We can leave the redirecting meta.zcml in zope.component > *forever*, if need be. It's not just the meta.zcml story, where I can agree we could leave something in place, but it's the dependencies in setup.py, right? If the implementation of the directives lives in zope.componentzcml, any codebase that loads any ZCML at all (in its tests especially) is very likely to need zope.componentzcml besides zope.component. Or am I missing something here? [snip] >> Anyway, this upgrade path needs to be spelled out clearly in the >> zope.component CHANGES.txt pointing people in the right direction. We >> also need to spell it out in this document: >> >> http://svn.zope.org/zope3docs/source/migration/34to35.rst > > Maintaining that document is out of scope for me. ;) If my above story about the dependencies is right, it is necessary to remark this in a central place. We do have framework-wide policies in place, and explaining to people how to unbreak their code in a single place they can look should be one of them. We do after all have people who use a whole bunch of these libraries at the same time. But if you can write it clearly in the CHANGES.txt and tell me, I'll add it to that document if you can't be bothered. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Stripping down zope.component
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: > Thanks for the clarifications concerning registries. Does the multiple > registry situation mean any changes to the implementation of the ZCML > directives at all or will they just work as soon the underlying registry > situation is adjusted? All the directive handlers do is create actions and add them to the parsing context: http://svn.repoze.org/repoze.zcml/trunk/repoze/zcml/__init__.py There isn't any there there, in the sense you are looking for. > Another point is that we need to make sure we have a path for libraries > that use zope.component[zcml] to upgrade. Actually, we don't need an upgrade path. We can just leave a 'meta.zcml' in zope.component which the new locations. That file will be *inert*, and doesn't therefore need testing, because none of the directive implementations will be present. Over time, people can shift to including the new meta.zcml at their leisure. We can leave the redirecting meta.zcml in zope.component *forever*, if need be. The subscribers registered in zope.component's configure.zcml are a different story: I have a YAGNI feeling in my gut about them, but haven't dug into who actually subscribes to verify it. At any rate, we can leave that zcml file as is unless / until we decide to rip out the zope.event dependency. > They will now need to import zope.componentzcml at the least, but where > does that leave zope.persistentregistry? Who needs to depend on this? > zope.site or something like that? zope.site doesn't need *persistent* registries. The traversal bit of the publisher just needs to notice that the traversed object implements the "I'm a site" interface, and call 'setSite'. The only code which *needs* persistent registries is the code which *implements* a registry as an attribute of a persistent object implementing that marker interface. > Anyway, this upgrade path needs to be spelled out clearly in the > zope.component CHANGES.txt pointing people in the right direction. We > also need to spell it out in this document: > > http://svn.zope.org/zope3docs/source/migration/34to35.rst Maintaining that document is out of scope for me. ;) > (I hope this and related documents will soon move to the 'zopeframework' > area) > > It'd be nice if we could organize some volunteers to check and adjust > any dependencies on zope.component that would need to be adjusted. I > think that mainly means checking those places that actually rely on > zope.component[zcml], but I think the baseregistry refactoring means > checking some other places as well. I think that the *real* clients of that extra are all the site.zcml files which which do the following: The tiny fraction of hardcore types who actually import the zope.component.zcml module are certainly competent to adjust those imports. 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 iD8DBQFJsIk5+gerLs4ltQ4RArFaAJ4m+OBOzd1zMszKu/UnmIwSgmGtkgCfbtso mRJBgLU7muEomTu04VjfnKw= =J4da -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Stripping down zope.component
Hi there, Thanks for the clarifications concerning registries. Does the multiple registry situation mean any changes to the implementation of the ZCML directives at all or will they just work as soon the underlying registry situation is adjusted? Another point is that we need to make sure we have a path for libraries that use zope.component[zcml] to upgrade. They will now need to import zope.componentzcml at the least, but where does that leave zope.persistentregistry? Who needs to depend on this? zope.site or something like that? Anyway, this upgrade path needs to be spelled out clearly in the zope.component CHANGES.txt pointing people in the right direction. We also need to spell it out in this document: http://svn.zope.org/zope3docs/source/migration/34to35.rst (I hope this and related documents will soon move to the 'zopeframework' area) It'd be nice if we could organize some volunteers to check and adjust any dependencies on zope.component that would need to be adjusted. I think that mainly means checking those places that actually rely on zope.component[zcml], but I think the baseregistry refactoring means checking some other places as well. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Stripping down zope.component
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
>> 4. Rework zope.hookable to use a pure-Python implementation via
>>descriptors, instead of the C extension. Make it a non-optional
>>dependency (but small and lightweight) of zope.component. If
>>*current* profiling shows that the hooked things are bottlenecks,
>>make the C version and optional replacement for the Python version.
>
> How do we do "current profiling"?
The existing implementation is the result of Jim's work profiling
component lookups back in 2002, using (I think) Python 2.2. I'm
suggesting that we think about redoing the profiling against the
versions we care about (2.5, 2.6), and reconsider whether pure-Python
alternatives, using newer language features, might be sufficient.
For another example of this idea, see my proposal last fall to
reimplement the pickle cache inside persistent using pure Python:
http://mail.zope.org/pipermail/zodb-dev/2008-September/012112.html
> Anyway, I'm +1 a pure-python implementation for zope.hookable, but we
> need to get some grasp of the performance implications nonetheless. Does
> anyone have any ideas on how determine the impact?
At the moment, the trunk of zope.component will use zope.hookable if it
is present, but fall back to a pure Python version if not. If any of
the bench code Jim and others used back in the original optimization
pass is still around, the comparing / profiling the two implementations
is where I would start.
> To get back to repoze.zcml: it is my understanding that repoze.zcml
> contains some fixes to the way component registration is done in the
> context of multiple WSGI applications. I'm no expert on this myself, so
> I may understand this wrong, but that is my understanding.
>
> If that is correct, we could look at applying these lessons to
> zope.componentzcml.
That isn't correct. repoze.zcml provides only alternative security-free
directive handlers, registered in a separate XML namespace. If other
folks want those handlers, they can use the package directly, or
somebody could migrate them into another zope.* package.
> The trouble starts because we'd also need to apply those lessons to
> grokcore.component as well, which doesn't need to depend on
> zope.componentzcml at all.
ZCML isn't really relevant: the problem I think you are worrying about
is actually in zope.component ("one global registry to rule them all").
The bits I think you are talking about are inside repoze.bfg's component
registry setup code:
http://svn.repoze.org/repoze.bfg/trunk/repoze/bfg/registry.py
which makes the "global" registry actually bound to a specific
"application". I don't know how reusable the code for that is, but the
idea should be liftable.
> So it would seem applying this knowledge would touch quite a few places,
> and my instinct is to look for a way to share the implementation and
> knowledge in a single place. We might be able do this by placing some
> basic action implementations (or at least code that helps implementing
> such actions) in zope.component itself. This would NOT implement any
> ZCML directives nor introduce any dependencies (not even
> zope.configuration), but would be an API implementers of configuration
> mechanisms could then use.
>
> Perhaps this is overkill or not possible; I don't quite understand the
> issues involved, but I hope someone who does chips in.
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
iD8DBQFJryLa+gerLs4ltQ4RAmGBAKDTJQUUxcisSbUoogkmhEdXxQkBHQCgr/9i
o+4meVIViWXh7E/I6SwNies=
=ptBg
-END PGP SIGNATURE-
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Stripping down zope.component
Hey, Thanks for reposting. It still shows up in the same thread for me, but I'll go with it. :) > I have a "strawman" proposal, focused on stripping zope.component down > as far as possible: > > 1. Merge my branch which drops the deferred import stuff. > > .. note: >I'm about to do this merge, based on positive feedback on the list. Great! > 2. Move the persistent registry stuff out into another package, >including whatever support is needed to allow for people to migrate >existing persistent references. Effectively, this moves one "extra" >out to a package, *including* its testing dependencies. +1 > 3. Move the ZCML directive implementations out into another package, >taking the zope.security and zope.configuration dependencies along >with them. +1 > 4. Rework zope.hookable to use a pure-Python implementation via >descriptors, instead of the C extension. Make it a non-optional >dependency (but small and lightweight) of zope.component. If >*current* profiling shows that the hooked things are bottlenecks, >make the C version and optional replacement for the Python version. How do we do "current profiling"? Anyway, I'm +1 a pure-python implementation for zope.hookable, but we need to get some grasp of the performance implications nonetheless. Does anyone have any ideas on how determine the impact? > .. note: >In the meanwhile, I have done the latter, with a pure-Python >'hookable' module in zope.component as a fallback for zope.hookable. +1 on this. > At the end, we would have three packages: > > zope.component > depends on: > - zope.interface > - zope.event > - zope.hookable (optional) > > zope.componentzcml (BIKESHED NAMING ALERT) > depends on: > - zope.configuration > - zope.security > - zope.configuration > - zope.proxy > - zope.i18nmessageid > > zope.persistentregistry (BIKESHED NAMING ALERT) > depends on: > - zope.configuration > - ZODB3 I'm fine with this naming. :) > Folks could then work on refactoring the new packages (e.g., depending > on a separate 'persistent' package, making the secuirity bits optional, > etc.). > Yes, this would be a great start, thanks very much for taking this initiative! To get back to repoze.zcml: it is my understanding that repoze.zcml contains some fixes to the way component registration is done in the context of multiple WSGI applications. I'm no expert on this myself, so I may understand this wrong, but that is my understanding. If that is correct, we could look at applying these lessons to zope.componentzcml. The trouble starts because we'd also need to apply those lessons to grokcore.component as well, which doesn't need to depend on zope.componentzcml at all. So it would seem applying this knowledge would touch quite a few places, and my instinct is to look for a way to share the implementation and knowledge in a single place. We might be able do this by placing some basic action implementations (or at least code that helps implementing such actions) in zope.component itself. This would NOT implement any ZCML directives nor introduce any dependencies (not even zope.configuration), but would be an API implementers of configuration mechanisms could then use. Perhaps this is overkill or not possible; I don't quite understand the issues involved, but I hope someone who does chips in. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Stripping down zope.component
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (reposted at Martijn's request in a new thread). Martijn Faassen wrote: > Hi there, > > Paul Everitt wrote: > [snip] >> Hopefully the Zope Framework proposal helps untangle this, and gets to a >> point where you don't have to keep the Uberthing in your head when doing >> something small. > > It's not small, as it has an impact on a lot of things that build on > zope.component. Changing things low in something that lots of people > have built stacks on is almost never a small change. > > Just look at Python 3, which makes a bunch of actually rather small but > still incompatible changes to the language. While small from the > perspective of the language, they're *huge* from the perspective of the > users. > > So you need ways to coordinate such changes. > > I hope that having someone actually taking responsibility for > zope.component's evolution can get the zope.security dependency out of > it, and then improvements of repoze.zcml into it, or alternatively move > the ZCML implementations *entirely* out of zope.component. I hope Chris > will coordinate with us where necessary. > > I don't want security bits to sit around in zope.component either. > grokcore.component doesn't need that code, just like repoze.zcml doesn't > need that code. It's still there, even if you use repoze.zcml, just > inactive. I tried to propose various ways forward. I got nowhere as I > got 10 people giving 10 answers. Original problem unresolved. > > I'd like there to be someone who can make this decision and I'd like > this someone to usually make *positive* decisions that work towards > resolving the underlying issue, while coordinating with everybody that > is impacted by this decision. > > The zope.component ZCML case was very much in my head as I wrote this > proposal. OK, can we table the proposal per se for the moment, and "prototype" the process around the "how do we move zope.component forward" question? I'm not even sure I understand why you think anything in repoze.zcml has squat to do with zope.component, but I could just be missing the obvious. I have a "strawman" proposal, focused on stripping zope.component down as far as possible: 1. Merge my branch which drops the deferred import stuff. .. note: I'm about to do this merge, based on positive feedback on the list. 2. Move the persistent registry stuff out into another package, including whatever support is needed to allow for people to migrate existing persistent references. Effectively, this moves one "extra" out to a package, *including* its testing dependencies. 3. Move the ZCML directive implementations out into another package, taking the zope.security and zope.configuration dependencies along with them. 4. Rework zope.hookable to use a pure-Python implementation via descriptors, instead of the C extension. Make it a non-optional dependency (but small and lightweight) of zope.component. If *current* profiling shows that the hooked things are bottlenecks, make the C version and optional replacement for the Python version. .. note: In the meanwhile, I have done the latter, with a pure-Python 'hookable' module in zope.component as a fallback for zope.hookable. At the end, we would have three packages: zope.component depends on: - zope.interface - zope.event - zope.hookable (optional) zope.componentzcml (BIKESHED NAMING ALERT) depends on: - zope.configuration - zope.security - zope.configuration - zope.proxy - zope.i18nmessageid zope.persistentregistry (BIKESHED NAMING ALERT) depends on: - zope.configuration - ZODB3 Folks could then work on refactoring the new packages (e.g., depending on a separate 'persistent' package, making the secuirity bits optional, etc.). 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 iD8DBQFJrxQl+gerLs4ltQ4RAgpLAJ0bOowoDHcKmcdolDjoFT+eTisUhACg2Bt0 wZ7SzkMMpBd1Q89z2qilc0Q= =Kl5M -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
