Metadata-Version: 1.1
Name: repoze.zope2
Version: 1.0.3
Summary: Zope2 via WSGI and Paste
Home-page: http://www.repoze.org
Author: Agendaless Consulting
Author-email: repoze-dev@lists.repoze.org
License: BSD-derived (http://www.repoze.org/LICENSE.txt)
Description: Overview
        
          repoze.zope2 is a decomposition of the Zope 2 appserver publication
          machinery (ZPublisher) into a WSGI application component.  It relies
          on separately-distributed middleware pieces to perform some of the
          features previously handled by ZPublisher and other parts of Zope 2.
        
        Installing repoze.zope2
        
          With a Python 2.4 interpreter >= 2.4.3 (**Python 2.5+ is
          unsupported**) with setuptools installed, install the 'virtualenv'
          package::
        
            $PYTHONHOME/bin/easy_install virtualenv
        
          When this is done, create a virtualenv "sandbox" to hold the
          repoze.zope2 packages and instance data:
        
            $PYTHONHOME/bin/virtualenv --no-site-packages /path/to/sandbox
        
          A directory named 'sandbox' will be created in the /path/to.
          directory.  You can use any path you like.
        
          After creating a virtualenv sandbox, install the 'repoze.zope2' egg
          into the virtualenv.
        
            /path/to/sandbox/bin/easy_install -i http://dist.repoze.org/simple repoze.zope2
        
          NOTE: Some "Syntax Error" messages may be printed to the console
          during this process; these can be ignored.  This is distutils
          attempting to byte-compile Zope "Python Scripts" in skin directories
          that aren't valid Python syntax.  
        
          After the repoze.zope2 packages are installed into the virtualenv,
          you can finally create "instance" files (config files) within the
          sandbox by running "mk2zope2instance"::
        
            /path/to/sandbox/bin/mkzope2instance
        
          After these steps have been performed, here's what has happened::
        
          - a "virtual Python" has been installed within the
            "/path/to/sandbox" directory.  Packages installed to this virtual
            Python's 'site-packages' directory will not conflict with packages
            installed into your "normal" Python's 'site-packages' directory.
        
          - All packages required by repoze.zope2 have beeen downloaded,
            compiled, and installed as Python eggs in the *virtual* Python's
            'site-packages' directory.
        
          - 'Products', 'logs', 'var', and 'etc' directories have been created
            inside the sandbox directory.  'Products' is where 3rd party Zope
            products should be installed.  'logs' is where Zope logs will go,
            'var' is where ZODB data files will go, 'etc' is where config
            files are placed.
        
          - A sample set of configuration files have been installed into the
            sandbox directory's 'etc' subdirectory.  These include::
        
            - 'zope.ini', a Paste configuration file used to establish the
              Paste (WSGI) pipeline which repoze.zope2 will use to serve up
              repoze.zope2.
        
            - 'zope.conf', a classic Zope 2 configuration file which can be
              used to adjust Zope settings.
        
            - 'site.zcml', a boilerplate site.zcml that should be used to
              control ZCML processing.
        
        The Default Sandbox Configuration
        
          The configuration of WSGI components in the sandbox setup form a
          publishing environment in which most Zope applications should be
          able to run without modification.  Some of the jobs previously
          filled by components in Zope have been assumed by repoze and other
          WSGI middleware components:
        
          - The job of ZServer has been filled by the zope 3 WSGI server (via
            repoze.zope2.server).
        
          - The job of ZPublisher object publishing has been filled by the
            object publisher in repoze.zope2
        
          - The job of ZPublisher transaction management has been filled by
            repoze.tm middleware.
        
          - The Zope 2 "error_log" has been replaced with error-catching /
            error-logging middleware in Paste.  (Visit /__error_log__ to see
            the exception history).
        
          - "access" logging can now be handled by a middleware component.
        
          - The job of VirtualHostMonster is now filled by repoze.vhm.
        
        Utilities
        
          These utilities are available in the "bin/" directory of the
          generated sandbox.
        
          installproduct -- provided the directory path of a classic Zope 2
          Product (unpacked), installproduct will attempt to convert the
          product into a Python egg and install it into the sandbox's
          site-packages directory.  This is an alternative to unpacking
          putting the product inside the sandbox "Products" directory.
        
          addzope2user -- script which adds a management user to the Zope root
          user folder.
        
          runzope2script -- script which runs a Python script with the root
          Zope application object as the "app" object in the globals
          namespace.
        
          debugzope2 -- runs the Python interactive interpreter with the Zope
          root object bound to the "app" name in the global dictionary/
        
          mkzope2instance -- create zope2 instance files in a directory.
        
        Testing repoze.zope2
        
          To all run repoze.zope2 tests, after running setup.py sandbox, cd to
          the repoze.zope2 directory and run::
        
            $sandboxdir/bin/python setup.py test
        
        Starting repoze.zope2
        
          To start a server that serves up a demo app on port 8080, cd to the
          sandbox directory you created via "setup.py sandbox" and run::
        
            bin/paster serve etc/zope2.ini
        
          When you visit http://localhost:8080/ in a browser, you should see
          the Zope 2 quickstart page.
        
          To manage the resulting Zope 2 site, you'll need to add a
          management user.  From the sandbox directory, run::
        
            bin/zope2adduser <username> <password>
        
          Once this is done, you should be able to visit
          http://localhost:8080/manage and log in with the username and
          password you supplied.
        
        Deploying
        
          Due to its simplicity, the default "sandbox" server is preferred for
          development and for some forms of deployment, but to make life
          easier for people more experienced with Apache technologies than
          Zope technologies, a reasonable deployment target for repoze.zope2
          is Apache via "mod_wsgi":http://code.google.com/p/modwsgi/ .
          mod_wsgi is an Apache module that allows you to run WSGI
          applications using the Apache HTTP server.
        
          A sample ".wsgi" deployment script (an analogue of the ones
          described in the mod_wsgi documentation) is available in the
          doc/sample_zope2.wsgi file.  A sample Apache configuration which
          uses this deployment script is included in the
          doc/sample_apache2.conf file.
        
          It's suggested that you serve up repoze.zope2 with mod_wsgi in
          "daemon mode" where each if the mod_wsgi's daemon children runs a
          single-threaded Zope process.  All of the Zope processes should
          communicate with a single ZEO server on the back end.  You can run a
          ZEO server by invoking "bin/zeoctl start -C etc/zeo.conf" from
          within a Repoze sandbox.  You'll need to change etc/zope.conf,
          uncommenting the <zodb_db> section that refers to a client storage
          at that point for Zope to work.
        
        
        
          
        
        
        
        CHANGES
        
        1.0.3 (2009-10-12)
        
          - Fix URL quoting on ACTUAL_URL and URL (both need to be quoted).
        
        1.0.2 (2009-08-31)
        
          - Add support for views-on-exceptions. This exists in Zope 2.12 and prior
            to that via the FiveException package. You can now register a view onto
            an exception class with the name 'index.html'. If found, this will be
            rendered when the exception is caught. Note that the transaction will be
            aborted regardless. This feature only works on ZODB 3.8 and later, because
            it depends on the 'doom()' feature of that version. If doom() is not
            available, the exception view will be ignored.
        
          - Calculate PATH_TRANSLATED in the same way as Zope 2.
        
          - Respect VIRTUAL_URL when computing ACTUAL_URL. VIRTUAL_URL may be set up
            repoze.vhm >= 0.11, for example, and contains the URL that the user sees.
        
          - When virtual hosting using repoze.vhm is used, and there is a VHM root,
            and if that path is present in the PATH_INFO, avoid traversing to the
            VHM root objects twice.
        
        1.0.1 (2009-26-8)
        
          - If an IPublishTraverse raises KeyError or AttributeError, the standard
            Zope 2 publisher treats it as a 404. Now z2bob does as well.
        
        1.0 (2008-28-11)
        
          - No changes from 0.4.6; declare it 1.0 in order to kick off the 1.X
            branch.  The repoze.zope2 trunk will now be the home of the 2.X
            version.
        
        0.4.6 (2008-07-03)
        
          - During helper teardown, clear out reference to request.response,
            so in case the request is leaked, the tempfile associated with the
            response isn't.
        
        0.4.5 (2008-06-26)
        
          - Make disable_gc only happen at initialization.  Drool.
        
        0.4.4 (2008-06-25)
        
          - Add a configuration flag for the app:zope2 section: 'disable_gc'.
            If this flag exists and is true, disable Python garbage collection
            for the interpreter used to start the process.  This flag probably
            doesn't belong here.
        
          - More explictly call noSecurityManager and clear out instance
            variables in the bob helper's .teardown method in case a helper
            ever leaks.
        
          - Belatedly change Trove classifier to "Development Status :: 4 - Beta"
            (it was "Development Status :: 1 - Planning").
        
        0.4.3 (2008-06-18)
        
          - Dont attempt any retries on conflict errors at startup.
            This was never tested, and probably didn't work.
        
          - Headers added to the response via "response.addHeaders" (aka
            accumulated_headers) were not returned in the response header
            list.
        
          - Properly unquote PATH_INFO segments into
            TraversalRequestNameStack.
        
        0.4.2 (2008-06-11)
        
          - Deal with Unauthorized exceptions properly: allow
            RESPONSE._unauthorized to be run and return a value rather than
            unconditionally triggering a basic authentication dialog.
        
            This version depends on repoze.obob 0.4+.
        
        0.4.1 (2008-05-27)
        
          - Use view lookup as well as getattr in next_name to detect whether
            a browser default page actually exists in order to support Zope
            2.9 "Five.traversable" semantics: getattr alone doesn't work under
            2.9 to detect whether a default view exists or not.
        
        0.4.0 (2008-05-21)
        
          - Raise an error Z2BobHelper's map_result method detects that it's
            about to return a value to obob which does not have an __iter__
            method.  This avoids confusion about what's causing failures when
            we attempt to publish an "unpublishable" object.
        
          - Fix a not-true-enough emulation of Zope 2.9 publishing semantics.
            Symptom: Z3 "adding" views being published without an acquisition
            wrapper under Zope 2.9.
        
        0.3.9 (2008-05-08)
        
          - Instance creation now expands the sandbox path in derived files
            (e.g. $INSTANCE in zope.conf).
        
          - Do not depend on ZODB3 3.7.2.  zopelib ships with a copy of ZODB.
            This was initially intended as a "convenience upgrade", but let's
            not impose it on people.  That said, repoze.retry has a dependency
            on a ZODB3 so we'll just wind up with whatever version of ZODB3
            happens to be in the index being used anyway.
        
          - Add a setup.cfg that specifies:
        
            [easy_install]
            index_url = http://dist.repoze.org/zope2/2.10/simple
        
            This overrides the default PyPI index URL.  Because we removed
            dependency-links and we don't publish our eggs to PyPI, it is
            required to allow "setup.py test", "setup.py develop", and
            "setup.py install" to work without the specification of an
            '--index_url' argument ("test" doesn't even take one).
        
          - Do not use a dependency-links= in setup.py.  Instead, trust the
            index to provide the right software.
        
          - Remove explicit version dependencies from install_requires and
            test_requires.  Use whatever versions of the software are in our
            index.
        
          - Provide support for Zope 2.9 (previously support was limited to
            Zope 2.10+).
        
          - ZServer didn't call app_iter.close after it finished a request as
            required by the WSGI spec (found via Paste#lint).
        
        0.3.8 (2008-05-02)
        
          - Cause zope2testrunner to sys.exit with a nonzero exit code when
            any tests fail (for usage under buildbot).
        
          - Filter warnings during addzope2user.
        
        0.3.7 (2008-04-18)
        
          - "Legacy" (VHM) virtual hosting was broken for virtual host roots
            that contained more than one path element (e.g. /plone/folder).
        
          - Overhauled "browser default" handling by moving code out of
            before_invoke into next_name in the Z2 obob helper.  We now treat
            browser default names such as 'index_html' as just another
            traversal step.
        
          - Depend on repoze.vhm 0.6, which re-adds support for
            path-segment-based virtual hosting parameters (as
            egg:repoze.vhm#vhm_path).
        
        0.3.6 (2008-04-16)
        
          - "http" exceptions (like Redirect and Unauthorized) weren't handled
            properly anywhere except in the repoze.zope2 obob helper's
            'invoke' step.  In-the-wild code uses these exceptions before the
            published object has been located (e.g. during traverse() or
            before_traverse()).  We now depend on repoze.obob >=0.3 to get
            extended exception handling behavior, and we implement a
            'handle_exception' method on our z2bob helper which will turn
            Zope2 Unauthorized and Redirect exceptions into their
            "httpexception" equivalents for consumption by upstream
            middleware.  This was prompted by code found in the wild in
            Plone's OpenId implementation which raises a redirect during
            traversal.
        
        0.3.5 (2008-04-16)
        
          - "Legacy" virtual hosting (via Virtual Host Monster) did not work
            properly.  Symptom: if you set up proxy-rewrite rules in Apache
            pointing at the Zope root a repoze.zope2 server running under a
            separate paster server, and tried to visit the ZMI via the Apache
            virtualhost's /manage URL, you'd be presented with the
            VirtualHostMonster ZMI configuration page instead of the ZMI's
            framed root UI.  Reason: the PARENTS[0] item was not set up early
            enough (it was set up in traverse rather than
            before_traverse). Since it was depended on by Zope API's which VHM
            called out to to set the virtual root, this didn't work, and the
            resulting traversal name stack was incorrect.
        
        0.3.4 (2008-03-24)
        
          - Bump ez_setup.py version.
        
          - When Zope 2 starts, it potentially writes data to the database
            during product initialization.  When multiple clients talk to the
            same ZEO storage at startup, they often simultaneously try to
            write (the same) information to the database concurrently.  This
            causes startup failure due to conflict errors.  We now retry
            product initialization up to five times to work around this issue.
        
        0.3.3 (2008-03-10)
        
          - repoze.zope2 now properly respects virtual host directives
            provided to it by repoze.vhm xheaders middleware >= 0.4.  Zope's
            VHM can still be used as necessary, but is no longer required.
        
        0.3.2 (2008-03-03)
        
          - Fix bug reported by Martin Aspeli: repoze.zope2 would choke on
            large images and files (symptom: broken images when images were
            large).  This was due to the fact that the Zope File- and
            Image-rendering machinery used HTTPResponse.write, which
            repoze.zope2's response handling didn't handle properly.  We now
            subclass HTTPResponse (as RepozeHTTPResponse) to solve the issue.
        
        0.3.1 (2008-03-02)
        
          - mkzope2instance now:
        
            o takes no arguments, only options.  '-d' replaces the single
              argument path.
        
            o creates a "log" directory
        
            o writes out a zeo.conf into "etc" (unconditionally); you can
              start a ZEO instance after installation now via 'bin/runzeo -C
              etc/zeo.conf', after ensuring that the 'address' in the ZEO
              section is correct.
        
            o allows the specification of 'sandbox' (-s) (replaces
              single-argument instancedir), 'zeo-port' (-z) , 'zope-port'
              (-p), and 'use-zeo' (-z) options.  If 'use-zeo' is specified,
              the zope.conf that's written will use a ClientStorage by
              default.
        
            o writes a zope.conf with a zodb cache-size of 50000 rather than
              10000.
        
          - addzope2user, runzope2script, and debugzope2 now respect a
            "ZOPE_CONF" environment variable, which can be used to specify the
            zope.conf configuration file to use.
        
          - Add a sample <zodb_db main> section to the generated zope.conf
            that can be uncommented if the installer wants to use ZEO instead
            of FileStorage or vice versa.
        
          - Added an (experimental) 'zope2testrunner' script that sets up
            stuff in the environment before running
            'zope.testing.testrunner.run'.  It accepts the same arguments as
            the Zope 3 testrunner.  E.g. 'bin/zope2testrunner -m
            Products.faster'.  This also respects the ZOPE_CONF envvar.
        
          - Depend on Zope 2.10.5 (zopelib-2.10.5.0) instead of 2.10.4.2 and
            various other updated repoze libraries.
            
        0.3.0
        
          - Install a mkzope2instance script as a console script to support
            non-repozeproject based installs.
        
          - Change documentation to prefer non-repozeproject installations.
        
        0.2.9
        
          - Fix up noncompliant WSGI environment server keys (
            CHANNEL_CREATION_TIME was an integer, QUERY_STRING
            didn't always exist) in "zserver".
        
          - Make zope2.wsgi mod_wsgi shim actually 
            work (Carlos de la Guardia).
        
        0.2.8
        
          - Ensure that the REQUEST['URL'] is as computed as possible before
            calling __bobo_traverse__/__getitem__/whatever during traversal to
            fix a ZMI-related bug.  Symptom: when adding folders or Python
            Scripts, the redirect back to manage_main would either do nothing
            or would cause a traceback.
        
          - Made setuptools 'description' include CHANGES.txt.
        
        0.2.7
        
          - Don't make a 'doc' directory, but make an 'import' directory
            during sandbox creation.
        
          - During traversal via __bobo_traverse__, turn any KeyError,
            AttributeError, and zExceptions.NotFound into
            paste.httpexceptions.NotFound error.
        
          - During traversal via __getattr__, turn AttributeError into a
            paste.httpexceptions.NotFound error.
        
          - During traversal via __getitem__, turn KeyError into a
            paste.httpexceptions.NotFound error.
        
          - Ensure that request['URL'] is not unicode when inserting it into
            the body during _insertBaseTag (or it turns the body into unicode
            too, after we've tried to ensure that it's not unicode with a
            typecheck and cast).
        
          - Depend on repoze.errorlog >= 0.4, and cause our default error log
            handler to ignore httpexceptions.HTTPNotFound, httpexceptions.HTTPFound,
            and httpexceptions.Unauthorized.
        
        0.2.6
        
          - Depend on repoze.errorlog and put it in the default pipeline.
            Visit '/__error_log__' to see exception history.  We do this
            because under Repoze, the Zope through-the-web 'error_log'
            exception history view is always empty.  Use this instead.
        
          - Implement WebDAV support.
        
        0.2.5
        
          - Fix read from RESPONSE.write (it also writes headers).
        
        0.2.4
        
          - Depend on repoze.vhm >= 0.3.
        
          - Allow RESPONSE.write to work (implemented using a temp file).
        
        0.2.3
        
         - Implement XML-RPC marshalling.
        
         - Get maintainer email address right.
        
         - Ditch 'python setup.py sandbox' in favor of documenting
           repoze.project-based install (see README.txt).
        
        0.2.2
        
         - Zope2ObobHelper.setup() was URL-quoting the ACTUAL_URL value.  This
           caused usage of Plone's login portlet to fail (symptom: keyerror on
           "http:").
        
        0.2.1
        
         - Add explicit ZODB3 requirement (>= 3.7.2, < 3.8.0a1), because repoze.tm
           and repoze.retry have relaxed their requirements, and might therefore
           bring in a ZODB incompatible with our zopelib version.
        
        0.2
        
         - Use repoze.obob 0.2 publishing semantics in order to be able to
           continue respecting 'TraversalRequestNameStack' (CMF modifies this
           stack in before-traversal hooks in CMFDynamicType).  This fixes
           Plone/CMF (symptoms: Plone front page not shown properly; 'edit'
           link for front page pointed to portal instead of default front-page
           content).
        
         - Close the ZPublisher HTTPRequest at obob "teardown" time.  This
           appears to fix a problem where CMF skin method names could not be
           found while running CMF and Plone Symptom: transient and
           intermittent AttributeError, NotFound error, or KeyError when
           attempting to render a page which used skins when running under the
           Paste http, PasteScript wsgiutils, or repoze.zope2.server WSGI
           servers.  Under mod_wsgi, this symptom was never evident.
        
         - Allowed the number of threads to be configurable in the
           repoze.zope2.server WSGI server (threads option in server config
           section).
        
        0.1
        
          Initial release.
        
        
Keywords: web application server wsgi zope
Platform: UNKNOWN
Classifier: Development Status :: 5 - Production/Stable
Classifier: Intended Audience :: Developers
Classifier: Programming Language :: Python
Classifier: Topic :: Internet :: WWW/HTTP
Classifier: Topic :: Internet :: WWW/HTTP :: Dynamic Content
Classifier: Topic :: Internet :: WWW/HTTP :: WSGI
Classifier: Topic :: Internet :: WWW/HTTP :: WSGI :: Application
