-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Rationale - --------
The focus of the 2011 Pyramid GSoC project has been to port crucial Pyramid dependencies to Python3:
https://github.com/Pylons/pyramid/wiki/Python-3-Porting
At the end of this year's US PyCon, Lennart Regebro labelled[1] zope.component as "high-hanging fruit", due to the following factors::
- - "magic"
- - Mostly tested via doctests
- - "Hairy" dependencies (e.g., zope.proxy, zope.security)
- - Many more optional / testing dependencies (ZODB3, zope.schema, zope.configuration, etc.)
Based on IRC discussion at project kickoff[2], Joel Bohman, one of the two Pyramid GSoC students, has tackled this issue by factoring zope.component into two pieces:
- - Joel has moved the core registry bits into a new 'zope.registry' package, now hosted in the Zope SVN repository:
http://svn.zope.org/zope.registry/trunk
Notes on the new package:
- The tests in this package have been converted to standard unit tests: they all pass on Python 2.6, 2.7, and 3.2.
- The "hairy" and optional / testing dependencies drop out: zope.registry depends only on zope.interface and zope.event.
- - Joel made zope.component depend on zope.registry in a branch:
http://svn.zope.org/zope.component/jbohman-zope.registry
This branch leaves BBB imports intact.
Proposal - --------
On bahalf of Joel and the Pyramid GSoC project, I would like to propose the following changes to the ZTK trunK:
- - Land 'zope.registry' as a full ZTK package, with its own Launchpad artifacts, etc. This step may also involve moving bugs from zope.component to zope.registry.
- - Merge the 'jbohman-zope.registry' branch of zope.component to the trunk, and bump its minor version accordingly.
- - Cut releases of both packages.
Once done, the remaining work to port zope.component should be smaller (much of the "magic" bits are now in zope.registry). We will update pyramid to use zope.registry in place of zope.component.
[1] http://permalink.gmane.org/gmane.comp.web.zope.devel/26373
[2] http://irclogs.rulim.de/%23pyramid/%23pyramid.2011-05-19.log.html#t2011-05-1...
Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com
Hello,
On Tue, 16 Aug 2011 22:50:42 -0400 you wrote:
trunk, and bump its minor version accordingly.
- Merge the 'jbohman-zope.registry' branch of zope.component to the
That sounds to me to rather have a *major* version number bump.
On Wed, Aug 17, 2011 at 8:12 AM, Adam GROSZER agroszer@gmail.com wrote:
On Tue, 16 Aug 2011 22:50:42 -0400 you wrote:
- Merge the 'jbohman-zope.registry' branch of zope.component to the
trunk, and bump its minor version accordingly.
Great work, +1 on merging (I trust the GSoC mentor did a good code review... ;)
That sounds to me to rather have a *major* version number bump.
If backwards compatible imports are left in place, I don't mind it being a 3.11.0 - but it might just as well be time to call it 4.0 :)
Hanno
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/17/2011 02:12 AM, Adam GROSZER wrote:
Hello,
On Tue, 16 Aug 2011 22:50:42 -0400 you wrote:
- Merge the 'jbohman-zope.registry' branch of zope.component to
the trunk, and bump its minor version accordingly.
That sounds to me to rather have a *major* version number bump.
Moving from zope.component 3.10.x to 3.11.0 signals "new dependencies / new features, but backwards compatible," which fits here, I think. Moving to 4.0 would signal "likely backwards incompatible."
I'm fine either way.
Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com
Hi,
On 17 August 2011 03:50, Tres Seaver tseaver@palladion.com wrote:
- Land 'zope.registry' as a full ZTK package, with its own Launchpad
artifacts, etc. This step may also involve moving bugs from zope.component to zope.registry.
This is not a major issue, but just be aware that there's a widely-used package plone.registry (which, in fact, has no dependencies beyond the ZTK) that serves a rather different purpose (http://pypi.python.org/pypi/plone.registry). It may be a bit confusing to people if we have a zope.registry that means something else, so perhaps we could call it something else?
As I said, not a major concern.
Martin
Hello,
* Tres Seaver tseaver@palladion.com [2011-08-16 22:50]:
The focus of the 2011 Pyramid GSoC project has been to port crucial Pyramid dependencies to Python3. At the end of this year's US PyCon, Lennart Regebro labelled[1] zope.component as "high-hanging fruit", due to the following factors::
- "magic"
- Mostly tested via doctests
- "Hairy" dependencies (e.g., zope.proxy, zope.security)
- Many more optional / testing dependencies (ZODB3, zope.schema, zope.configuration, etc.)
Based on IRC discussion at project kickoff[2], Joel Bohman, one of the two Pyramid GSoC students, has tackled this issue by factoring zope.component into two pieces:
- Joel has moved the core registry bits into a new 'zope.registry' package, now hosted in the Zope SVN repository:
- Joel made zope.component depend on zope.registry in a branch:
I applaud both the direction of porting to Python3 and the drive towards cleaning up / streamlining the ZTK packages. That's great!
However, I feel that this extraction of the registry bits is a little too mechanical, and I'd like us to think a little bit about alternative approaches before we commit this.
I envision the ZTK packages (like zope.component) to become more standalone, less coupled to "the whole Zope world", but cohesive pieces of functionality that can stand on its own.
In that light, I'd like to ask: what should be in zope.component, and what shouldn't? My first stab at an answer goes something like this:
zope.component (aka the Zope Component Architecture) consists of - the Registry concept - filling out the Adapter concept of zope.interface - the Site concept (setSiteManager, aka hooks.py) - integration with zope.event (? a bit unsure here) Something like that would make a coherent, usable package, I think.
At the moment, though, zope.component also contains (triggered via different extra_requires): - integration with zope.configuration (the <adapter/> and <utility/> directives) - integration with zope.security - integration with ZODB (persistent registries)
Those integration bits with "other parts of the Zope world" don't need to be in there, I guess -- and as I understand it, precisely those are the "hairy" dependencies that impede porting to py3.
So I'd like to propose to do the split the other way around: Not extract the core into something else and leave only a hollowed-out shell of integration and miscellany stuff behind, but rather tighten zope.component to its core and move the optional integration bits out of it, into separate packages.
What do people think?
Wolfgang
On Thu, Aug 25, 2011 at 2:50 AM, Wolfgang Schnerring ws@gocept.com wrote: ...
So I'd like to propose to do the split the other way around: Not extract the core into something else and leave only a hollowed-out shell of integration and miscellany stuff behind, but rather tighten zope.component to its core and move the optional integration bits out of it, into separate packages.
What do people think?
I would agree if we were starting over. But the damage is done and stripping zope.component to its core would be backwards incompatible now.
This is, OTOH, an opportunity to maybe come up with a more appealing name. While I like the term "component", my sense is that it probably feels too heavy to a lot of Python programmers. "Registry" is at least as bad and doesn't reflect the real use case.
Maybe something like "zope.plugins" would be better. When I try to explain zope.component to people, I often explain it as a good generic plugin mechanism.
Jim
On 25/08/2011 06:24, Jim Fulton wrote:
Maybe something like "zope.plugins" would be better. When I try to explain zope.component to people, I often explain it as a good generic plugin mechanism.
If we're renaming, we could also consider dropping the "zope" bit.
I never will understand the irrational fear and hatred of the "zope" name but it's still there and I reckon we'd get a much more sensible reception in the rest of the python world if we dropped it.
cheers,
Chris
PS: In passing, and for similar reasons, along with ease of pronunciation and lack of package namespacing, it'd be great if buildout 2.0 could be just "buildout" rather than zc.buildout.
* Jim Fulton jim@zope.com [2011-08-25 15:24]:
On Thu, Aug 25, 2011 at 2:50 AM, Wolfgang Schnerring ws@gocept.com wrote:
So I'd like to propose to do the split the other way around: Not extract the core into something else and leave only a hollowed-out shell of integration and miscellany stuff behind, but rather tighten zope.component to its core and move the optional integration bits out of it, into separate packages.
I would agree if we were starting over. But the damage is done and stripping zope.component to its core would be backwards incompatible now.
Why? zope.component already uses extras_require to signify the various integration parts: [persistentregistry,security,zcml].
As far as I understand the thrust of the zope.registry effort, it is to untangle those to make porting easier (which requires those bits not to be in the same package, I guess, because of import problems or whatnot?).
I think the same effect could also be achieved by splitting these integration bits into separate packages, and leaving the extras_require's in zope.component to depend on said new packages, couldn't it?
But that's only technicalities in search of meaningfully preserving the name zope.component for the core package (because that's the name it always had), and...
This is, OTOH, an opportunity to maybe come up with a more appealing name. While I like the term "component", my sense is that it probably feels too heavy to a lot of Python programmers. "Registry" is at least as bad and doesn't reflect the real use case.
... I agree that an alternative is to give the core a new name.
However, what's important to me is that we try to make packages cohesive, and that we try to make integration between packages understandable.
The current zope.component, because it came out of the Zope3 monolith, contains integration bits to various other Zope packages: - zope.event - zope.security - zope.configuration - ZODB
In that light, it makes a lot of sense to me to have two (or more?) packages, "core" and "integration", but I'd *very* much like them to be named in a way that one can tell this fact from their names.
What remains is the issue that zope.component *also* contains code for the thread-local site concept -- which doesn't feel like an integration with another package, but might not be considered core functionality, either (I'm not sure yet but I lean towards considering it core).
Wolfgang
Am 26.08.2011, 09:51 Uhr, schrieb Wolfgang Schnerring ws@gocept.com:
However, what's important to me is that we try to make packages cohesive, and that we try to make integration between packages understandable. The current zope.component, because it came out of the Zope3 monolith, contains integration bits to various other Zope packages:
- zope.event
- zope.security
- zope.configuration
- ZODB
In that light, it makes a lot of sense to me to have two (or more?) packages, "core" and "integration", but I'd *very* much like them to be named in a way that one can tell this fact from their names. What remains is the issue that zope.component *also* contains code for the thread-local site concept -- which doesn't feel like an integration with another package, but might not be considered core functionality, either (I'm not sure yet but I lean towards considering it core).
Wolfgang,
I think that what you suggest is too much for the moment and I think it even contains the Zope 3 risk of trying to get everything right. I have the feeling that getting things right is going to take a lot more head-scratching and beard-pulling!
Tres' proposal has the not inconsiderable advantage of merging work already done. You are right to point out inconsistencies and warts but against that should be weighed the possibility of making a port to Python 3.x a real possibility. And, given that the work has come from an external if related project, the main aim of exposing these libraries to the wider world has been achieved.
So from +1 for Tres proposal and +1 for a roadmap on this.
Regarding Withers suggestion - should we be looking to move these libraries to the WSGI namespace? Or are there real use cases outside the web world?
Charlie
Regarding Withers suggestion - should we be looking to move these libraries to the WSGI namespace? Or are there real use cases outside the web world?
I use zope.component outside of web related development. I don't really care what namespace it is in, but zope.component/zope.interface are not just for the web/wsgi, so I have use case ;-)
For instance I use it in generating python code from UML models for a range of different applications.
Just my 2c
T
On 26/08/2011 02:17, Charlie Clark wrote:
Regarding Withers suggestion - should we be looking to move these libraries to the WSGI namespace? Or are there real use cases outside the web world?
As with Tim, I use both of these libraries plenty of the time outside of web work...
cheers,
Chris
Hello Charlie,
* Charlie Clark charlie.clark@clark-consulting.eu [2011-08-26 11:17]:
Am 26.08.2011, 09:51 Uhr, schrieb Wolfgang Schnerring ws@gocept.com:
However, what's important to me is that we try to make packages cohesive, and that we try to make integration between packages understandable.
I think that what you suggest is too much for the moment and I think it even contains the Zope 3 risk of trying to get everything right.
I fully agree that it is not feasible to do everything at once, and that we should take small but continuous steps towards the goal. But my aim was first and foremost to point out that the currently proposed step is going *in the wrong direction* in my opinion. Upon that it's a little disheartening to hear that I'm trying to do too much.
Tres' proposal has the not inconsiderable advantage of merging work already done.
This feels a lot like "the facts are already there, end of discussion" to me, and I hope you agree that this is not a reasonable argument.
And, given that the work has come from an external if related project, the main aim of exposing these libraries to the wider world has been achieved.
That is true and I'm glad we're leaving the monolithic state "it's all of Zope or nothing" behind more and more. However, to mention the goal again (which is worth moving towards, I think), I really think we should not split things up "just so" according to current mechanical requirements, but also think about conceptual boundaries.
Wolfgang
On Fri, Aug 26, 2011 at 3:51 AM, Wolfgang Schnerring ws@gocept.com wrote:
- Jim Fulton jim@zope.com [2011-08-25 15:24]:
On Thu, Aug 25, 2011 at 2:50 AM, Wolfgang Schnerring ws@gocept.com wrote:
So I'd like to propose to do the split the other way around: Not extract the core into something else and leave only a hollowed-out shell of integration and miscellany stuff behind, but rather tighten zope.component to its core and move the optional integration bits out of it, into separate packages.
I would agree if we were starting over. But the damage is done and stripping zope.component to its core would be backwards incompatible now.
Why? zope.component already uses extras_require to signify the various integration parts: [persistentregistry,security,zcml].
But it still contains code to go with those dependencies. To clean this up, you'd have to remove that code, which would cause breakage.
As far as I understand the thrust of the zope.registry effort, it is to untangle those to make porting easier (which requires those bits not to be in the same package, I guess, because of import problems or whatnot?).
I think the same effect could also be achieved by splitting these integration bits into separate packages, and leaving the extras_require's in zope.component to depend on said new packages, couldn't it?
It could if you didn't care about backwards compatibility.
But that's only technicalities in search of meaningfully preserving the name zope.component for the core package (because that's the name it always had), and...
It would still have that name.
This is, OTOH, an opportunity to maybe come up with a more appealing name. While I like the term "component", my sense is that it probably feels too heavy to a lot of Python programmers. "Registry" is at least as bad and doesn't reflect the real use case.
... I agree that an alternative is to give the core a new name.
However, what's important to me is that we try to make packages cohesive, and that we try to make integration between packages understandable.
That's everyone's goal. The current contents of zope.component aren't all that cohesive. I haven't looked at the registry branch but I assume and hope that the registry package includes the core functionality.
The current zope.component, because it came out of the Zope3 monolith,
That's not right. When Zope3 was managed as a single whole, zope.component was far more cohesive and less tangled than it is now. It gained a bunch of cruft in the rush to kill zope.app.component when code was moved from zope.app.component was mistakenly moved to zope.component.
The reason we created zope.app in the first place was to prevent application-framework-specific policies from polluting the more general packages.
contains integration bits to various other Zope packages:
- zope.event
I think treating integration with zope.event as core would be reasonable.
- zope.security
- zope.configuration
- ZODB
In that light, it makes a lot of sense to me to have two (or more?) packages, "core" and "integration", but I'd *very* much like them to be named in a way that one can tell this fact from their names.
Me too. I wish the destruction of zope.app.component had happened differently. I'd like to have meaningful names, but I'd rather not incur more backwards incompatibility to get them.
It's certainly valid to argue for the backward incompatibility. It's a tradeoff.
What remains is the issue that zope.component *also* contains code for the thread-local site concept -- which doesn't feel like an integration with another package, but might not be considered core functionality, either (I'm not sure yet but I lean towards considering it core).
IMO, what's core is a way to plug in component registries, not a particular strategy for component registries.
Jim
* Jim Fulton jim@zope.com [2011-08-26 07:35]:
On Fri, Aug 26, 2011 at 3:51 AM, Wolfgang Schnerring ws@gocept.com wrote:
- Jim Fulton jim@zope.com [2011-08-25 15:24]:
stripping zope.component to its core would be backwards incompatible now.
Why? zope.component already uses extras_require to signify the various integration parts: [persistentregistry,security,zcml].
But it still contains code to go with those dependencies. To clean this up, you'd have to remove that code, which would cause breakage.
I have the feeling I'm missing or overlooking something. Could you help me find it? These are the two scenarios, as I understand them:
a) zope.component declares an extras_require "foo", making it depend on zope.foo, and also has a module zope.component.foo with integration code in it.
b) zope.component declares an extras_require "foo", making it depend on zope.foo *and* a new package zope.component_foo (which contains the extracted integration code). Also, zope.component has BBB imports in zope.component.foo that point to zope.component_foo.
My understanding is that from a client's perspective these two are equivalent: if you want the foo functionality for zope.component, you have to depend on zope.component[foo], and you import stuff from zope.component.foo.
The current zope.component, because it came out of the Zope3 monolith,
That's not right. When Zope3 was managed as a single whole, zope.component was far more cohesive and less tangled than it is now. It gained a bunch of cruft in the rush to kill zope.app.component when code was moved from zope.app.component was mistakenly moved to zope.component.
Ah, I wasn't properly aware of that part of its history. Thanks for clarifying!
I think treating integration with zope.event as core would be reasonable.
That makes sense. Event handlers certainly feel like a useful (and widely-used) feature to me.
- zope.security
- zope.configuration
- ZODB
In that light, it makes a lot of sense to me to have two (or more?) packages, "core" and "integration", but I'd *very* much like them to be named in a way that one can tell this fact from their names.
Me too. I wish the destruction of zope.app.component had happened differently. I'd like to have meaningful names, but I'd rather not incur more backwards incompatibility to get them.
It's certainly valid to argue for the backward incompatibility. It's a tradeoff.
I think I don't want to argue for incompatibility, but rather I am glad that we are exploring what degrees of freedom for improvement remain available to us while still preserving compatibility.
What remains is the issue that zope.component *also* contains code for the thread-local site concept -- which doesn't feel like an integration with another package, but might not be considered core functionality, either (I'm not sure yet but I lean towards considering it core).
IMO, what's core is a way to plug in component registries, not a particular strategy for component registries.
Do I understand you correctly that the fact that getSiteManager is "hookable" should be core, but the thread-local mechanism of setSite() should not? That seems like a very useful delimination.
Wolfgang
On Tue, Aug 30, 2011 at 2:23 AM, Wolfgang Schnerring ws@gocept.com wrote:
- Jim Fulton jim@zope.com [2011-08-26 07:35]:
On Fri, Aug 26, 2011 at 3:51 AM, Wolfgang Schnerring ws@gocept.com wrote:
- Jim Fulton jim@zope.com [2011-08-25 15:24]:
stripping zope.component to its core would be backwards incompatible now.
Why? zope.component already uses extras_require to signify the various integration parts: [persistentregistry,security,zcml].
But it still contains code to go with those dependencies. To clean this up, you'd have to remove that code, which would cause breakage.
I have the feeling I'm missing or overlooking something. Could you help me find it? These are the two scenarios, as I understand them:
a) zope.component declares an extras_require "foo", making it depend on zope.foo, and also has a module zope.component.foo with integration code in it.
b) zope.component declares an extras_require "foo", making it depend on zope.foo *and* a new package zope.component_foo (which contains the extracted integration code). Also, zope.component has BBB imports in zope.component.foo that point to zope.component_foo.
So in b, you'd move the integration code to a separate package that becomes part of the extras.
My understanding is that from a client's perspective these two are equivalent: if you want the foo functionality for zope.component, you have to depend on zope.component[foo], and you import stuff from zope.component.foo.
Except that probably many (most?) clients of zope.component don't bother to name the extras because they depend on the other dependencies anyway, for other reasons.
I don't have any data to back this up, but it might be useful to look at something like Blue Bream to see if the packages in it that depend on zope.component include the extras. I'd bet $.05 that they don't.
You're right though that if projects that use zope.component are careful to use extras accurately, then the integration code could be moved out as long as the extras themselves are retained (and enhanced). You could even argue that clients that don't declare needed extras are broken and deserve to lose.
Note that I added the extras in desperation several years ago as I was preparing to teach a PyCon zope.component tutorial and was horrified to discover that depending on zope.component would bring in most of Zope 3. I was hoping to make the point that zope.component could be used outside of Zope. Ironically, most or all of the students were Zope users anyway, so my point was largely moot. :/
It could have been argued at the time that adding the extras was a backward-incompatible change, but I don't think it effected anyone. At least I never heard that it did, which supports my assumption that people are already depending on the dependencies named in the extras and aren't bothering to name them.
...
IMO, what's core is a way to plug in component registries, not a particular strategy for component registries.
Do I understand you correctly that the fact that getSiteManager is "hookable" should be core, but the thread-local mechanism of setSite() should not? That seems like a very useful delimination.
Yes.
Jim
-- Jim Fulton http://www.linkedin.com/in/jimfulton
* Jim Fulton jim@zope.com [2011-08-30 09:25]:
On Tue, Aug 30, 2011 at 2:23 AM, Wolfgang Schnerring ws@gocept.com wrote:
My understanding is that from a client's perspective these two are equivalent: if you want the foo functionality for zope.component, you have to depend on zope.component[foo], and you import stuff from zope.component.foo.
Except that probably many (most?) clients of zope.component don't bother to name the extras because they depend on the other dependencies anyway, for other reasons.
Yes, right, I see that now. Thanks for clarifying!
Hmm, I guess I'm going to lose if I try to argue that not naming the extra is "wrong" and thus deserves no respect or compatibility protection, am I not?
Wolfgang
On Thu, 2011-08-25 at 08:50 +0200, Wolfgang Schnerring wrote:
However, I feel that this extraction of the registry bits is a little too mechanical, and I'd like us to think a little bit about alternative approaches before we commit this.
I envision the ZTK packages (like zope.component) to become more standalone, less coupled to "the whole Zope world", but cohesive pieces of functionality that can stand on its own.
In that light, I'd like to ask: what should be in zope.component, and what shouldn't? My first stab at an answer goes something like this:
zope.component (aka the Zope Component Architecture) consists of
- the Registry concept
- filling out the Adapter concept of zope.interface
- the Site concept (setSiteManager, aka hooks.py)
- integration with zope.event (? a bit unsure here)
Something like that would make a coherent, usable package, I think.
At the moment, though, zope.component also contains (triggered via different extra_requires):
- integration with zope.configuration (the <adapter/> and <utility/> directives)
- integration with zope.security
- integration with ZODB (persistent registries)
Those integration bits with "other parts of the Zope world" don't need to be in there, I guess -- and as I understand it, precisely those are the "hairy" dependencies that impede porting to py3.
So I'd like to propose to do the split the other way around: Not extract the core into something else and leave only a hollowed-out shell of integration and miscellany stuff behind, but rather tighten zope.component to its core and move the optional integration bits out of it, into separate packages.
What do people think?
I'm -1 on redefining the meaning of zope.component. Otoh, if the name "zope.registry" (or the introduction of a new package) is a problem, I'd suggest we move the stuff that is currently in "zope.registry" to zope.interface. zope.interface already contains a bunch of registry-related code; it'd make complete sense to me.
- C
* Chris McDonough chrism@plope.com [2011-08-26 13:27]:
So I'd like to propose to do the split the other way around: Not extract the core into something else and leave only a hollowed-out shell of integration and miscellany stuff behind, but rather tighten zope.component to its core and move the optional integration bits out of it, into separate packages.
I'm -1 on redefining the meaning of zope.component.
I'm afraid I don't understand what you're saying. Could you expand on this? What meaning is redefined to what by which proposed action(s)?
Otoh, if the name "zope.registry" (or the introduction of a new package) is a problem, I'd suggest we move the stuff that is currently in "zope.registry" to zope.interface. zope.interface already contains a bunch of registry-related code; it'd make complete sense to me.
That's an interesting suggestion, since zope.interface contains the bigger half of all the adapter mechanics already. (zope.interface would gain the concept "utility", an adapter "from" nothing, but I wouldn't mind that, I guess.)
However, my main driving point here is coherent package boundaries, and as said elsewhere in this thread, I think that the core of zope.component comprises more than just the Registry class, namely the (hookable) getSiteManager protocol and probably zope.event integration -- and I'm not sure that all this belongs into zope.interface.
Wolfgang
On Tue, 2011-08-30 at 08:47 +0200, Wolfgang Schnerring wrote:
- Chris McDonough chrism@plope.com [2011-08-26 13:27]:
So I'd like to propose to do the split the other way around: Not extract the core into something else and leave only a hollowed-out shell of integration and miscellany stuff behind, but rather tighten zope.component to its core and move the optional integration bits out of it, into separate packages.
I'm -1 on redefining the meaning of zope.component.
I'm afraid I don't understand what you're saying. Could you expand on this? What meaning is redefined to what by which proposed action(s)?
My interpretation of your suggestion is that maybe that "zope.component" end up as what "zope.registry" is now. But I don't think preserving the name "zope.component" for this small core and spinning off everything else in the package into separate bits is very attractive, because "zope.component" is just a name and we can do it with a lot less churn and potential for bw incompat if we just rename the core bits rather than changing the meaning of "zope.component" to be "just the core bits".
If there's some solution that doesn't break bw compat but gets what you're after, I couldn't possibly be opposed to it. But I don't see how it can happen without some backwards incompatibility, even if that backwards incompatibility is the requirement that a user install setuptools extras to get what used to come along with the core.
Otoh, if the name "zope.registry" (or the introduction of a new package) is a problem, I'd suggest we move the stuff that is currently in "zope.registry" to zope.interface. zope.interface already contains a bunch of registry-related code; it'd make complete sense to me.
That's an interesting suggestion, since zope.interface contains the bigger half of all the adapter mechanics already. (zope.interface would gain the concept "utility", an adapter "from" nothing, but I wouldn't mind that, I guess.)
However, my main driving point here is coherent package boundaries, and as said elsewhere in this thread, I think that the core of zope.component comprises more than just the Registry class, namely the (hookable) getSiteManager protocol and probably zope.event integration -- and I'm not sure that all this belongs into zope.interface.
As far as I'm concerned, the ZCA global API and zope.event machinery are not "guts"; they are convenience APIs on top of the guts. Each promotes the idea that there is a single registry per process, which is not always true (it's not in Pyramid, anyway). I'd be a -1 on seeing these sorts of convenience APIs come along for the ride into the "guts" package, whatever that ends up being.
- C
* Chris McDonough chrism@plope.com [2011-08-30 03:51]:
If there's some solution that doesn't break bw compat but gets what you're after, I couldn't possibly be opposed to it. But I don't see how it can happen without some backwards incompatibility, even if that backwards incompatibility is the requirement that a user install setuptools extras to get what used to come along with the core.
Ahhhh. *slaps forehead*
There's my thinking mistake. Currently, the extras_require is *not* necessary to get the integration bits, clients can depend on *only* zope.component. That would have to change with my idea, and that's not bw compatible. Right.
I have to think this over (at least) once more.
Wolfgang
* Chris McDonough chrism@plope.com [2011-08-30 03:51]:
On Tue, 2011-08-30 at 08:47 +0200, Wolfgang Schnerring wrote: My interpretation of your suggestion is that maybe that "zope.component" end up as what "zope.registry" is now. But I don't think preserving the name "zope.component" for this small core and spinning off everything else in the package into separate bits is very attractive, because "zope.component" is just a name and we can do it with a lot less churn and potential for bw incompat if we just rename the core bits rather than changing the meaning of "zope.component" to be "just the core bits".
Yep, that's a fitting assessment.
I have two concerns, the more important one is to establish a clear definition of what concepts and functionality constitute the Zope Component Architecture (in other words, for the most part, what of everything that currently is in zope.component does actually belong there?) and to keep these core bits intact when we're extracting and/or pruning.
The second one is that the established package name for the ZCA has been zope.component, and that I'd rather keep it that way. But I guess I'd be willing to concede that point and take up a new name, since I agree that trying to keep it probably requires more churn and headaches than changing it. But I also guess I'd like the new name to be more evocative than "zope.registry". Yes, I fully realize the bikesheeding potential, and I'm sorry (a little at least ;-), but the ZCA is so much at the core of the Zope world I feel it deserves some consideration so as to carry a fitting name.
By the way, while we're taking up new names and leaving zope.component intact as bw compat, can we use that opportunity to clean up the terminology a little? For example, class Components should IMHO become class Registry, and getSiteManager could be something like getCurrentRegistry.
**
To take up the "what is the ZCA" question again, I don't know if this helps or confuses, but here goes: yesterday we (Thomas Lotze, Michael Howitz and myself) brainstormed at the office whiteboard and came up with stuff the ZCA is used for in Zope3-ish applications:
- Dependency Injection to promote inversion of control (utilities) - Multiple dispatch to promote extensibility (adapters) - Event handlers to promote decoupling (subscribers) - Plain old configuration (any of the above can be bent towards that purpose, my "favourite" example being how the default view name is handled... ouch.) - The notion of a context in which the application runs and that informs its behaviour (in Zope3 terms, the "site"; more on that below)
These seem to be quite different things, and I'm not certain they *should* be all together in one place, but on the other hand, extracting zope.registry as proposed seems to me to take out just slices of each (think "vertical stripes") and leave other parts of each behind in zope.component, which seems to me the wrong way around ("horizontal stripes" would be better).
As far as I'm concerned, the ZCA global API and zope.event machinery are not "guts"; they are convenience APIs on top of the guts. Each promotes the idea that there is a single registry per process, which is not always true (it's not in Pyramid, anyway). I'd be a -1 on seeing these sorts of convenience APIs come along for the ride into the "guts" package, whatever that ends up being.
I don't think zope.component.getSiteManager() promotes a single registry per process, but rather (although maybe just as jarring) the concept of a "current registry".
While personally I'm not so sure anymore that this is a Good Thing(tm), I feel it is quite fundamental to how zope.component is used and thought about. If you take this notion away, of a context in which code runs and which provides a current registry, no more IFoo(bar) and no more simple getUtility, but you'll have to explicitly retrieve or pass around the registry. (I guess Pyramid does it like that? The registry lives on the request and that is passed around throughout the framework?)
Wolfgang
On Thu, 2011-09-01 at 09:15 +0200, Wolfgang Schnerring wrote:
- Chris McDonough chrism@plope.com [2011-08-30 03:51]:
On Tue, 2011-08-30 at 08:47 +0200, Wolfgang Schnerring wrote: My interpretation of your suggestion is that maybe that "zope.component" end up as what "zope.registry" is now. But I don't think preserving the name "zope.component" for this small core and spinning off everything else in the package into separate bits is very attractive, because "zope.component" is just a name and we can do it with a lot less churn and potential for bw incompat if we just rename the core bits rather than changing the meaning of "zope.component" to be "just the core bits".
Yep, that's a fitting assessment.
I have two concerns, the more important one is to establish a clear definition of what concepts and functionality constitute the Zope Component Architecture (in other words, for the most part, what of everything that currently is in zope.component does actually belong there?) and to keep these core bits intact when we're extracting and/or pruning.
The second one is that the established package name for the ZCA has been zope.component, and that I'd rather keep it that way. But I guess I'd be willing to concede that point and take up a new name, since I agree that trying to keep it probably requires more churn and headaches than changing it. But I also guess I'd like the new name to be more evocative than "zope.registry". Yes, I fully realize the bikesheeding potential, and I'm sorry (a little at least ;-), but the ZCA is so much at the core of the Zope world I feel it deserves some consideration so as to carry a fitting name.
By the way, while we're taking up new names and leaving zope.component intact as bw compat, can we use that opportunity to clean up the terminology a little? For example, class Components should IMHO become class Registry, and getSiteManager could be something like getCurrentRegistry.
**
To take up the "what is the ZCA" question again, I don't know if this helps or confuses, but here goes: yesterday we (Thomas Lotze, Michael Howitz and myself) brainstormed at the office whiteboard and came up with stuff the ZCA is used for in Zope3-ish applications:
- Dependency Injection to promote inversion of control (utilities)
- Multiple dispatch to promote extensibility (adapters)
- Event handlers to promote decoupling (subscribers)
- Plain old configuration (any of the above can be bent towards that purpose, my "favourite" example being how the default view name is handled... ouch.)
- The notion of a context in which the application runs and that informs its behaviour (in Zope3 terms, the "site"; more on that below)
These seem to be quite different things, and I'm not certain they *should* be all together in one place, but on the other hand, extracting zope.registry as proposed seems to me to take out just slices of each (think "vertical stripes") and leave other parts of each behind in zope.component, which seems to me the wrong way around ("horizontal stripes" would be better).
The machinery that makes possible the first three of your "stripes" above wind up in zope.registry in the current plan, aside from convenience global APIs. The fourth is a concept that doesn't really have any code analogue. The last would continue to be provided by zope.component, at least for Zope, which tends to use the global registry and various registries encountered during traversal.
As far as I'm concerned, the ZCA global API and zope.event machinery are not "guts"; they are convenience APIs on top of the guts. Each promotes the idea that there is a single registry per process, which is not always true (it's not in Pyramid, anyway). I'd be a -1 on seeing these sorts of convenience APIs come along for the ride into the "guts" package, whatever that ends up being.
I don't think zope.component.getSiteManager() promotes a single registry per process, but rather (although maybe just as jarring) the concept of a "current registry".
While personally I'm not so sure anymore that this is a Good Thing(tm), I feel it is quite fundamental to how zope.component is used and thought about. If you take this notion away, of a context in which code runs and which provides a current registry, no more IFoo(bar) and no more simple getUtility, but you'll have to explicitly retrieve or pass around the registry. (I guess Pyramid does it like that? The registry lives on the request and that is passed around throughout the framework?)
Yes, it gets attached to the request. We also make it available via a threadlocal, but, by default, we don't hook getSiteManager() to make this possible. Instead we just maintain our own threadlocal registry and provide an API that allows people to obtain the registry without having a request in-hand. Using this API is an "in case of emergency break glass" sort of thing in Pyramid.
But in Pyramid the registry is much more an implementation detail than it is in Zope. The framework uses it, and developers use it indirectly via APIs we provide, but they don't often interact with it directly; they really don't even know it exists. Most Pyramid developers don't use their own adapters and utilities in their own applications, although of course they can. We don't support IFoo(bar) at all at module scope, as there's no "current registry" at import time.
It wouldn't be the end of the world to have the global registry and the global API live in zope.registry, but it doesn't help Pyramid for it to be in there, and it probably wouldn't help anyone else either. The global API (which includes getSiteManager) is really just a convenience feature, and splitting that global API across more than one package doesn't seem to make sense to me.
It might make sense for the entire global API to be in zope.registry, but if you take "global API" to mean what it does now that implies dependencies on at least:
- zope.event (zope.component.event.dispatch)
- zope.testing (for addCleanUp of the global registry in z.c.globalregistry and other places)
It also implies conditional dependencies on zope.security (in z.c.hooks.setSite, and other places), which are even now pretty nasty.
I'd be -1 on that if only due to the extra dependencies.
- C
On Thu, Sep 1, 2011 at 4:27 AM, Chris McDonough chrism@plope.com wrote: ...
- zope.testing (for addCleanUp of the global registry in
z.c.globalregistry and other places)
This particular detail should simply be cleaned up by moving these calls into tests module.
Jim
On Thu, 2011-09-01 at 09:22 -0400, Jim Fulton wrote:
On Thu, Sep 1, 2011 at 4:27 AM, Chris McDonough chrism@plope.com wrote: ...
- zope.testing (for addCleanUp of the global registry in
z.c.globalregistry and other places)
This particular detail should simply be cleaned up by moving these calls into tests module.
This is in zope.component.globalregistry at module scope:
base = BaseGlobalComponents('base')
try: from zope.testing.cleanup import addCleanUp except ImportError: pass else: addCleanUp(lambda: base.__init__('base')) del addCleanUp
I didn't see that the registration was conditional on the presence of zope.testing last night, but if I understand the intent correctly, it's to ensure that importing z.component at all will add a cleanup callback to zope.testing such that z.testing.cleanUp() will wipe the global registry state. Lots of existing tests will break if this isn't done, so I'm not sure that moving it into a place where it isn't executed as a side effect is feasible?
- C
On Thu, Sep 1, 2011 at 1:28 PM, Chris McDonough chrism@plope.com wrote:
On Thu, 2011-09-01 at 09:22 -0400, Jim Fulton wrote:
On Thu, Sep 1, 2011 at 4:27 AM, Chris McDonough chrism@plope.com wrote: ...
- zope.testing (for addCleanUp of the global registry in
z.c.globalregistry and other places)
This particular detail should simply be cleaned up by moving these calls into tests module.
This is in zope.component.globalregistry at module scope:
base = BaseGlobalComponents('base')
try: from zope.testing.cleanup import addCleanUp except ImportError: pass else: addCleanUp(lambda: base.__init__('base')) del addCleanUp
I didn't see that the registration was conditional on the presence of zope.testing last night, but if I understand the intent correctly, it's to ensure that importing z.component at all will add a cleanup callback to zope.testing such that z.testing.cleanUp() will wipe the global registry state. Lots of existing tests will break if this isn't done, so I'm not sure that moving it into a place where it isn't executed as a side effect is feasible?
I was thinking only of zope.component's tests. There's still the issue of tests of clients of zope.component, which my suggestion doesn't address.
Jim
* Chris McDonough chrism@plope.com [2011-09-01 04:27]:
It wouldn't be the end of the world to have the global registry and the global API live in zope.registry, but it doesn't help Pyramid for it to be in there, and it probably wouldn't help anyone else either. The global API (which includes getSiteManager) is really just a convenience feature, and splitting that global API across more than one package doesn't seem to make sense to me.
I guess this is the central issue where we have different opinions. I don't consider those "just convenience", but rather concept-bearing of their on right.
It might make sense for the entire global API to be in zope.registry, but if you take "global API" to mean what it does now that implies dependencies on at least:
- zope.event (zope.component.event.dispatch)
- zope.testing (for addCleanUp of the global registry in z.c.globalregistry and other places)
Yep, those two would be necessary.
It also implies conditional dependencies on zope.security (in z.c.hooks.setSite, and other places), which are even now pretty nasty.
But I don't see where that would come from. As far as I understand it, hooks.setSite wouldn't be in zope.registry.
Wolfgang
On Tue, 2011-09-06 at 12:50 +0200, Wolfgang Schnerring wrote:
- Chris McDonough chrism@plope.com [2011-09-01 04:27]:
It wouldn't be the end of the world to have the global registry and the global API live in zope.registry, but it doesn't help Pyramid for it to be in there, and it probably wouldn't help anyone else either. The global API (which includes getSiteManager) is really just a convenience feature, and splitting that global API across more than one package doesn't seem to make sense to me.
I guess this is the central issue where we have different opinions. I don't consider those "just convenience", but rather concept-bearing of their on right.
"Convenience" and "concept bearing" aren't mutually exclusive. Whom would be served if we moved the global API to zope.registry? Are you thinking that zope.registry would be some sort of "fresh start" for zope.component? If so, is anyone willing to promote it, write new docs, etc?
It might make sense for the entire global API to be in zope.registry, but if you take "global API" to mean what it does now that implies dependencies on at least:
- zope.event (zope.component.event.dispatch)
- zope.testing (for addCleanUp of the global registry in z.c.globalregistry and other places)
Yep, those two would be necessary.
This is a bit icky for me. I'd rather have something with fewer dependencies, or at least dependencies I actually use.
It also implies conditional dependencies on zope.security (in z.c.hooks.setSite, and other places), which are even now pretty nasty.
But I don't see where that would come from. As far as I understand it, hooks.setSite wouldn't be in zope.registry.
If we were to move all this stuff into zope.registry, I think we'd do just as well to leave zope.component as-is, but port all of its dependencies to Python 3. Although that's a noble goal, I personally won't be doing that any time soon; I'd instead just take the code we actually from zope.component and put it into Pyramid itself.
- C
* Chris McDonough chrism@plope.com [2011-09-06 20:06]:
On Tue, 2011-09-06 at 12:50 +0200, Wolfgang Schnerring wrote:
- Chris McDonough chrism@plope.com [2011-09-01 04:27]:
It wouldn't be the end of the world to have the global registry and the global API live in zope.registry, but it doesn't help Pyramid for it to be in there, and it probably wouldn't help anyone else either. The global API (which includes getSiteManager) is really just a convenience feature, and splitting that global API across more than one package doesn't seem to make sense to me.
I guess this is the central issue where we have different opinions. I don't consider those "just convenience", but rather concept-bearing of their on right.
"Convenience" and "concept bearing" aren't mutually exclusive. Whom would be served if we moved the global API to zope.registry? Are you thinking that zope.registry would be some sort of "fresh start" for zope.component? If so, is anyone willing to promote it, write new docs, etc?
Yes, I like the idea of a "fresh start" (or at least "proper clean up") quite a bit. And I'd definitely be up for writing (new) documentation. You've set a great example in that regard with Pyramid that is very much worth emulating for other packages.
It also implies conditional dependencies on zope.security (in z.c.hooks.setSite, and other places), which are even now pretty nasty.
But I don't see where that would come from. As far as I understand it, hooks.setSite wouldn't be in zope.registry.
If we were to move all this stuff into zope.registry, I think we'd do just as well to leave zope.component as-is, but port all of its dependencies to Python 3.
Isn't that a little too black and white? I find value in the idea of removing the dependencies to ZODB, ZCML and zope.security, while leaving zope.event/zope.testing in place.
Although that's a noble goal, I personally won't be doing that any time soon; I'd instead just take the code we actually from zope.component and put it into Pyramid itself.
I agree, porting "the whole hairball" is way too much, and I definitely wouldn't want to burden you/Pyramid with that.
Wolfgang
On Thu, 2011-09-08 at 09:01 +0200, Wolfgang Schnerring wrote:
- Chris McDonough chrism@plope.com [2011-09-06 20:06]:
On Tue, 2011-09-06 at 12:50 +0200, Wolfgang Schnerring wrote:
- Chris McDonough chrism@plope.com [2011-09-01 04:27]:
It wouldn't be the end of the world to have the global registry and the global API live in zope.registry, but it doesn't help Pyramid for it to be in there, and it probably wouldn't help anyone else either. The global API (which includes getSiteManager) is really just a convenience feature, and splitting that global API across more than one package doesn't seem to make sense to me.
I guess this is the central issue where we have different opinions. I don't consider those "just convenience", but rather concept-bearing of their on right.
"Convenience" and "concept bearing" aren't mutually exclusive. Whom would be served if we moved the global API to zope.registry? Are you thinking that zope.registry would be some sort of "fresh start" for zope.component? If so, is anyone willing to promote it, write new docs, etc?
Yes, I like the idea of a "fresh start" (or at least "proper clean up") quite a bit. And I'd definitely be up for writing (new) documentation. You've set a great example in that regard with Pyramid that is very much worth emulating for other packages.
I'm behind the goal of cleaning up and documenting componenty things better, and I think those are very worthy ideas. But I think blocking the proposed division while we hash out the details of what some second generation zope.component might be is probably not in anyone's best interest. If there were some branch laying around with a proposed set of changes, it might be more reasonable, but there's not, and it will take months to create one (after discussion, planning, development, rehashing, etc). The creation of a second package today that just holds the proposed bits doesn't prevent future innovation, AFAICT.
It also implies conditional dependencies on zope.security (in z.c.hooks.setSite, and other places), which are even now pretty nasty.
But I don't see where that would come from. As far as I understand it, hooks.setSite wouldn't be in zope.registry.
If we were to move all this stuff into zope.registry, I think we'd do just as well to leave zope.component as-is, but port all of its dependencies to Python 3.
Isn't that a little too black and white? I find value in the idea of removing the dependencies to ZODB, ZCML and zope.security, while leaving zope.event/zope.testing in place.
I don't share this particular goal, except for in a very general "yes it would be nice to clean stuff up" sort of way.
Although that's a noble goal, I personally won't be doing that any time soon; I'd instead just take the code we actually from zope.component and put it into Pyramid itself.
I agree, porting "the whole hairball" is way too much, and I definitely wouldn't want to burden you/Pyramid with that.
That's appreciated, but blocking the currently proposed division (at least without some alternative code) will have the same effect.
- C
* Chris McDonough chrism@plope.com [2011-09-08 05:21]:
On Thu, 2011-09-08 at 09:01 +0200, Wolfgang Schnerring wrote:
Yes, I like the idea of a "fresh start" (or at least "proper clean up") quite a bit. And I'd definitely be up for writing (new) documentation. You've set a great example in that regard with Pyramid that is very much worth emulating for other packages.
I'm behind the goal of cleaning up and documenting componenty things better, and I think those are very worthy ideas. But I think blocking the proposed division while we hash out the details of what some second generation zope.component might be is probably not in anyone's best interest. If there were some branch laying around with a proposed set of changes, it might be more reasonable, but there's not, and it will take months to create one (after discussion, planning, development, rehashing, etc). The creation of a second package today that just holds the proposed bits doesn't prevent future innovation, AFAICT.
I guess that extracting just a little bit right now won't get in the way of "doing things properly" (since that most likely means extracting a little more and then documenting it), and I certainly don't want to stand in the way there.
However, that means that the package currently called "zope.registry" will quite likely become the "future" of zope.component. In that light I'd really like to try and come up with a better name -- Jim?
Wolfgang
On Thu, 2011-09-08 at 13:39 +0200, Wolfgang Schnerring wrote:
- Chris McDonough chrism@plope.com [2011-09-08 05:21]:
On Thu, 2011-09-08 at 09:01 +0200, Wolfgang Schnerring wrote:
Yes, I like the idea of a "fresh start" (or at least "proper clean up") quite a bit. And I'd definitely be up for writing (new) documentation. You've set a great example in that regard with Pyramid that is very much worth emulating for other packages.
I'm behind the goal of cleaning up and documenting componenty things better, and I think those are very worthy ideas. But I think blocking the proposed division while we hash out the details of what some second generation zope.component might be is probably not in anyone's best interest. If there were some branch laying around with a proposed set of changes, it might be more reasonable, but there's not, and it will take months to create one (after discussion, planning, development, rehashing, etc). The creation of a second package today that just holds the proposed bits doesn't prevent future innovation, AFAICT.
I guess that extracting just a little bit right now won't get in the way of "doing things properly" (since that most likely means extracting a little more and then documenting it), and I certainly don't want to stand in the way there.
However, that means that the package currently called "zope.registry" will quite likely become the "future" of zope.component. In that light I'd really like to try and come up with a better name -- Jim?
I mentioned previously that it's not that much of a stretch to put this code into zope.interface because zope.interface.adapter already defines registry-ish stuff that possesses most of the same concepts as a component registry. It has a class named "AdapterRegistry" already that has a very similar API as a full-on component registry. The full-on component registry really just an API implemented in terms of multiple z.i.adapter.AdapterRegistry instances.
With that in mind, and in the interest of moving forward, I'd suggest we just ditch the zope.registry package and move its code into zope.interface. Then there's no renaming to do at all, we can still innovate in the future without necessarily decommissioning a package. As a bonus, we'll have one fewer dependency package.
The zope.registry registration machinery sends events when its API is called. It'd be a bit sucky to have z.event as a hard dependency of zope.interface. But it'd be dead easy to change it to only send registration events if zope.event could be imported. I doubt there's anything listening for these events that doesn't also already depend on zope.event.
zope.registry also currently provides a minor API in the way of an "adapts" decorator. This could (and should) be moved back into zope.component; it's actually not used internally by zope.registry now (although some decoy imports would make you think so if you look at zope.registry.__init__).
- C
On Thu, 2011-09-08 at 19:03 -0400, Chris McDonough wrote:
On Thu, 2011-09-08 at 13:39 +0200, Wolfgang Schnerring wrote:
- Chris McDonough chrism@plope.com [2011-09-08 05:21]:
On Thu, 2011-09-08 at 09:01 +0200, Wolfgang Schnerring wrote:
Yes, I like the idea of a "fresh start" (or at least "proper clean up") quite a bit. And I'd definitely be up for writing (new) documentation. You've set a great example in that regard with Pyramid that is very much worth emulating for other packages.
I'm behind the goal of cleaning up and documenting componenty things better, and I think those are very worthy ideas. But I think blocking the proposed division while we hash out the details of what some second generation zope.component might be is probably not in anyone's best interest. If there were some branch laying around with a proposed set of changes, it might be more reasonable, but there's not, and it will take months to create one (after discussion, planning, development, rehashing, etc). The creation of a second package today that just holds the proposed bits doesn't prevent future innovation, AFAICT.
I guess that extracting just a little bit right now won't get in the way of "doing things properly" (since that most likely means extracting a little more and then documenting it), and I certainly don't want to stand in the way there.
However, that means that the package currently called "zope.registry" will quite likely become the "future" of zope.component. In that light I'd really like to try and come up with a better name -- Jim?
I mentioned previously that it's not that much of a stretch to put this code into zope.interface because zope.interface.adapter already defines registry-ish stuff that possesses most of the same concepts as a component registry. It has a class named "AdapterRegistry" already that has a very similar API as a full-on component registry. The full-on component registry really just an API implemented in terms of multiple z.i.adapter.AdapterRegistry instances.
With that in mind, and in the interest of moving forward, I'd suggest we just ditch the zope.registry package and move its code into zope.interface. Then there's no renaming to do at all, we can still innovate in the future without necessarily decommissioning a package. As a bonus, we'll have one fewer dependency package.
The zope.registry registration machinery sends events when its API is called. It'd be a bit sucky to have z.event as a hard dependency of zope.interface. But it'd be dead easy to change it to only send registration events if zope.event could be imported. I doubt there's anything listening for these events that doesn't also already depend on zope.event.
zope.registry also currently provides a minor API in the way of an "adapts" decorator. This could (and should) be moved back into zope.component; it's actually not used internally by zope.registry now (although some decoy imports would make you think so if you look at zope.registry.__init__).
First cuts of this at:
http://svn.zope.org/zope.component/branches/chrism-zope.interface-componentr...
http://svn.zope.org/zope.interface/branches/chrism-componentregistry/
- C
On Fri, 2011-09-09 at 00:57 -0400, Chris McDonough wrote:
I mentioned previously that it's not that much of a stretch to put this code into zope.interface because zope.interface.adapter already defines registry-ish stuff that possesses most of the same concepts as a component registry. It has a class named "AdapterRegistry" already that has a very similar API as a full-on component registry. The full-on component registry really just an API implemented in terms of multiple z.i.adapter.AdapterRegistry instances.
With that in mind, and in the interest of moving forward, I'd suggest we just ditch the zope.registry package and move its code into zope.interface. Then there's no renaming to do at all, we can still innovate in the future without necessarily decommissioning a package. As a bonus, we'll have one fewer dependency package.
The zope.registry registration machinery sends events when its API is called. It'd be a bit sucky to have z.event as a hard dependency of zope.interface. But it'd be dead easy to change it to only send registration events if zope.event could be imported. I doubt there's anything listening for these events that doesn't also already depend on zope.event.
zope.registry also currently provides a minor API in the way of an "adapts" decorator. This could (and should) be moved back into zope.component; it's actually not used internally by zope.registry now (although some decoy imports would make you think so if you look at zope.registry.__init__).
First cuts of this at:
http://svn.zope.org/zope.component/branches/chrism-zope.interface-componentr...
http://svn.zope.org/zope.interface/branches/chrism-componentregistry/
I have merged these two branches to their respective trunks:
z.i: https://mail.zope.org/pipermail/checkins/2011-September/057121.html
z.c: https://mail.zope.org/pipermail/checkins/2011-September/057124.html
If no one has issues with this, I will make releases of both within the next few days.
- C
On 15/09/2011 07:11, Chris McDonough wrote:
zope.registry also currently provides a minor API in the way of an "adapts" decorator. This could (and should) be moved back into zope.component; it's actually not used internally by zope.registry now (although some decoy imports would make you think so if you look at zope.registry.__init__).
First cuts of this at:
http://svn.zope.org/zope.component/branches/chrism-zope.interface-componentr...
http://svn.zope.org/zope.interface/branches/chrism-componentregistry/
I have merged these two branches to their respective trunks:
z.i: https://mail.zope.org/pipermail/checkins/2011-September/057121.html
z.c: https://mail.zope.org/pipermail/checkins/2011-September/057124.html
A big enough change to warrant a second point bump rather than just third point, certainly for z.i, surely?
Chris
-
Adam GROSZER -
Charlie Clark -
Chris McDonough -
Chris Withers -
Hanno Schlichting -
Jim Fulton -
Martin Aspeli -
Tim Hoffman -
Tres Seaver -
Wolfgang Schnerring