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