GitLocker: The Coding Marketplace

Description:

repoze.zope2 1.0.3

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/easyinstallvirtualenvWhenthisisdone,createavirtualenv"sandbox"toholdtherepoze.zope2packagesandinstancedata: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:: Missing open brace for subscriptMissing open brace for subscriptINSTANCE 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.