[Zope-dev] RFC: Proposal for merging jbohman-zope.registry branch of zope.component

[Jim Fulton]

On Tue, Aug 30, 2011 at 2:23 AM, Wolfgang Schnerring <ws at gocept.com> wrote:
> * Jim Fulton <jim at zope.com> [2011-08-26 07:35]:
>> On Fri, Aug 26, 2011 at 3:51 AM, Wolfgang Schnerring <ws at gocept.com> wrote:
>> > * Jim Fulton <jim at 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