Features

--------

- Add ``setUp`` and ``tearDown`` functions to the
  ``repoze.bfg.testing`` module.  Using ``setUp`` in a test setup and
  ``tearDown`` in a test teardown is now the recommended way to do
  component registry setup and teardown.  Previously, it was
  recommended that a single function named
  ``repoze.bfg.testing.cleanUp`` be called in both the test setup and
  tear down.  ``repoze.bfg.testing.cleanUp`` still exists (and will
  exist "forever" due to its widespread use); it is now just an alias
  for ``repoze.bfg.testing.setUp`` and is nominally deprecated.

- The BFG component registry is now available in view and event
  subscriber code as an attribute of the request
  ie. ``request.registry``.  This fact is currently undocumented
  except for this note, because BFG developers never need to interact
  with the registry directly anywhere else.

- The BFG component registry now inherits from ``dict``, meaning that
  it can optionally be used as a simple dictionary.  *Component*
  registrations performed against it via e.g. ``registerUtility``,
  ``registerAdapter``, and similar API methods are kept in a
  completely separate namespace than its dict members, so using the
  its component API methods won't effect the keys and values in the
  dictionary namespace.  Likewise, though the component registry
  "happens to be" a dictionary, use of mutating dictionary methods
  such as ``__setitem__`` will have no influence on any component
  registrations made against it.  In other words, the registry object
  you obtain via e.g. ``repoze.bfg.threadlocal.get_current_registry``
  or ``request.registry`` happens to be both a component registry and
  a dictionary, but using its component-registry API won't impact data
  added to it via its dictionary API and vice versa.  This is a
  forward compatibility move based on the goals of "marco".

Documentation
-------------

- Various tutorial test modules updated to use
  ``repoze.bfg.testing.setUp`` and ``repoze.bfg.testing.tearDown``
  methods in order to encourage this as best practice going forward.

Backwards Incompatibilities
---------------------------

- Importing ``getSiteManager`` and ``get_registry`` from
  ``repoze.bfg.registry`` is no longer supported.  These imports were
  deprecated in repoze.bfg 1.0.  Import of ``getSiteManager`` should
  be done as ``from zope.component import getSiteManager``.  Import of
  ``get_registry`` should be done as ``from repoze.bfg.threadlocal
  import get_current_registry``.  This was done to prevent a circular
  import dependency.

- Code bases which alternately invoke both
  ``zope.testing.cleanup.cleanUp`` and ``repoze.bfg.testing.cleanUp``
  (treating them equivalently, using them interchangeably) in the
  setUp/tearDown of unit tests will begin to experience test failures
  due to lack of test isolation.  The "right" mechanism is
  ``repoze.bfg.testing.cleanUp`` (or the combination of
  ``repoze.bfg.testing.setUp`` and
  ``repoze.bfg.testing.tearDown``). but a good number of legacy
  codebases will use ``zope.testing.cleanup.cleanUp`` instead.  We
  support ``zope.testing.cleanup.cleanUp`` but not in combination with
  ``repoze.bfg.testing.cleanUp`` in the same codebase.  You should use
  one or the other test cleanup function in a single codebase, but not
  both.

Internal
--------

- Created new ``repoze.bfg.configuration`` module which assumes
  responsibilities previously held by the ``repoze.bfg.registry`` and
  ``repoze.bfg.router`` modules (avoid a circular import dependency).

- The result of the ``zope.component.getSiteManager`` function in unit
  tests set up with ``repoze.bfg.testing.cleanUp`` or
  ``repoze.bfg.testing.setUp`` will be an instance of
  ``repoze.bfg.registry.Registry`` instead of the global
  ``zope.component.globalregistry.base`` registry.  This also means
  that the threadlocal ZCA API functions such as ``getAdapter`` and
  ``getUtility`` as well as internal BFG machinery (such as
  ``model_url`` and ``route_url``) will consult this registry within
  unit tests. This is a forward compatibility move based on the goals
  of "marco".

- Removed ``repoze.bfg.testing.addCleanUp`` function and associated
  module-scope globals.  This was never an API.

1 files changed, 5 insertions, 54 deletions

diff --git a/repoze/bfg/registry.py b/repoze/bfg/registry.py
index 06cd1b804..796ac0dfa 100644
--- a/repoze/bfg/registry.py
+++ b/repoze/bfg/registry.py
@@ -1,21 +1,15 @@
-import threading
-
-from zope.component import getGlobalSiteManager
-from zope.component import getSiteManager as original_getSiteManager
 from zope.component.registry import Components
-from zope.deprecation import deprecated
-import zope.component
-
-from repoze.bfg.threadlocal import get_current_registry
-from repoze.bfg.threadlocal import manager
-from repoze.bfg.zcml import zcml_configure
 
-class Registry(Components):
+class Registry(Components, dict):
 
     # for optimization purposes, if no listeners are listening, don't try
     # to notify them
     has_listeners = False
 
+    def reset(self):
+        self.__init__(self.__name__)
+        self.clear()
+
     def registerSubscriptionAdapter(self, *arg, **kw):
         result = Components.registerSubscriptionAdapter(self, *arg, **kw)
         self.has_listeners = True
@@ -32,46 +26,3 @@ class Registry(Components):
             for ignored in self.subscribers(events, None):
                 """ """
 
-def populateRegistry(registry, filename, package, lock=threading.Lock(),
-                     manager=manager): # lock and manager for testing
-
-    """ We push our ZCML-defined configuration into an app-local
-    component registry in order to allow more than one bfg app to live
-    in the same process space without one unnecessarily stomping on
-    the other's component registrations (although I suspect directives
-    that have side effects are going to fail).  The only way to do
-    that currently is to override zope.component.getGlobalSiteManager
-    for the duration of the ZCML includes.  We acquire a lock in case
-    another make_app runs in a different thread simultaneously, in a
-    vain attempt to prevent mixing of registrations.  There's not much
-    we can do about non-makeRegistry code that tries to use the global
-    site manager API directly in a different thread while we hold the
-    lock.  Those registrations will end up in our application's
-    registry."""
-    
-    lock.acquire()
-    manager.push({'registry':registry, 'request':None})
-    try:
-        original_getSiteManager.sethook(get_current_registry)
-        zope.component.getGlobalSiteManager = get_current_registry
-        zcml_configure(filename, package)
-    finally:
-        zope.component.getGlobalSiteManager = getGlobalSiteManager
-        lock.release()
-        manager.pop()
-
-getSiteManager = get_current_registry # b/c
-
-deprecated('getSiteManager',
-           'As of repoze.bfg 1.0, any import of getSiteManager from'
-           '``repoze.bfg.registry`` is '
-           'deprecated.  Use ``from zope.compponent import getSiteManager '
-           'instead.')
-
-get_registry = get_current_registry # b/c
-
-deprecated('get_registry',
-           'As of repoze.bfg 1.0, any import of get_registry from'
-           '``repoze.bfg.registry`` is '
-           'deprecated.  Use ``from repoze.bfg.threadlocal import '
-           'get_current_registry instead.')