You are here: Home

Modified items

All recently modified items, latest first.
RPMPackage zope-zc.lockfile-1.2.1-1.lbn25.py37.noarch
The zc.lockfile package provides a basic portable implementation of interprocess locks using lock files. The purpose if not specifically to lock files, but to simply provide locks with an implementation based on file-locking primitives. Of course, these locks could be used to mediate access to other files. For example, the ZODB file storage implementation uses file locks to mediate access to file-storage database files. The database files and lock file files are separate files.
RPMPackage zope-zc.dict-1.3b1-2.lbn25.noarch
BTree-based persistent dict-like objects (regular dict and ordered) that can be used as base classes. This is a bit of a heavyweight solution, as every zc.dict.Dict (and zc.dict.OrderedDict) is at least 3 persistent objects. Keep this in mind if you intend to create lots and lots of these. To build, run ``python bootstrap/bootstrap.py`` and then ``bin/buildout`` from this directory. A clean, non-system Python is strongly recommended. An efficient, persistent and subclassable dict PersistentDict is very inefficient if it contains more than a couple of values, and BTrees are not recommended to inherit from. This class is a simple wrapper over a BTree. It retains the efficiency of BTrees and is safe to use as a base class. Also, it implements the full Python dict interface.
RPMPackage zope-zc.buildout-2.13.2-1.lbn25.noarch
Buildout is a project designed to solve 2 problems: 1. Application-centric assembly and deployment Assembly runs the gamut from stitching together libraries to create a running program, to production deployment configuration of applications, and associated systems and tools (e.g. run-control scripts, cron jobs, logs, service registration, etc.). Buildout might be confused with build tools like make or ant, but it is a little higher level and might invoke systems like make or ant to get it's work done. Buildout might be confused with systems like puppet or chef, but it is more application focused. Systems like puppet or chef might use buildout to get their work done. Buildout is also somewhat Python-centric, even though it can be used to assemble and deploy non-python applications. It has some special features for assembling Python programs. It's scripted with Python, unlike, say puppet or chef, which are scripted with Ruby. 2. Repeatable assembly of programs from Python software distributions Buildout puts great effort toward making program assembly a highly repeatable process, whether in a very open-ended development mode, where dependency versions aren't locked down, or in a deployment environment where dependency versions are fully specified. You should be able to check buildout into a VCS and later check it out. Two checkouts built at the same time in the same environment should always give the same result, regardless of their history. Among other things, after a buildout, all dependencies should be at the most recent version consistent with any version specifications expressed in the buildout. Buildout supports applications consisting of multiple programs, with different programs in an application free to use different versions of Python distributions. This is in contrast with a Python installation (real or virtual), where, for any given distribution, there can only be one installed. To learn more about buildout, including how to use it, see http://buildout.org/.
RPMPackage zope-zc-2.0.0-3.lbn25.noarch
Zope Corp base module hierarchy
RPMPackage zope-zLOG-3.0-1.lbn25.noarch
This package provides a general logging facility that, at this point, is just a small shim over Python’s logging module. Therefore, unless you need to support a legacy package from the Zope 2 world, you’re probably better off using Python’s logging module.
RPMPackage zope-zExceptions-2.13.0-2.lbn25.noarch
zExceptions contains common exceptions used in Zope2.
RPMPackage zope-z3c.zcmlhook-1.0b1-2.lbn25.noarch
z3c.zcmlhook
RPMPackage zope-z3c.widgets.flashupload-1.0c1-4.lbn25.noarch
 
RPMPackage zope-z3c.widgets-1.0c1-4.lbn25.noarch
Zope 3 widget base module hierarchy
RPMPackage zope-z3c.recipe.compattest-1.0-1.lbn25.noarch
This buildout recipe generates a list of packages to test and a test runner that runs each package’s tests (isolated from any other tests). This is useful to check that the changes made while developing a package do not break any packages that are using this package.
RPMPackage zope-z3c.pt-3.1.0-1.lbn25.noarch
This is a fast implementation of the ZPT template engine for Zope 3 which uses Chameleon to compile templates to byte-code. The package provides application support equivalent to zope.app.pagetemplate.
RPMPackage zope-z3c.objpath-1.1-1.lbn25.noarch
This package contains two things: * the z3c.objpath.interfaces.IObjectPath interface. * some helper functions to construct (relative) object paths, in z3c.objpath.path. The idea is that a particular application can implement a utility that fulfills the IObjectPath interface, so that it is possible to construct paths to objects in a uniform way. The implementation may be done with zope.traversing, but in some cases you want application-specific object paths. In this case, the functions in z3c.objpath.path might be useful.
RPMPackage zope-z3c.jbot-0.7.2-1.lbn25.noarch
Overview The z3c.jbot (or "Just a bunch of templates") package allows easy customization of existing templates and images. It works on Zope 2 and Zope 3. The Chameleon rendering engine is supported [1]. Use of this package adds a small (2-3 ms per request on Plone) to the total application response time. [1] To enable Chameleon on Zope 2, use the five.pt package (CMF-apps like Plone should use cmf.pt which adds full support). Usage To override a particular file, first determine its canonical filename. It's defined as the path relative to the package within which the file is located; directory separators are replaced with dots. Example: Suppose you want to override: /plone/app/layout/viewlets/logo.pt You would use the filename: plone.app.layout.viewlets.logo.pt Simply drop the file in a directory and register that directory for use with jbot using a ZCML-directive: <include package="z3c.jbot" file="meta.zcml" /> <browser:jbot directory="<path>" layer="<layer>" /> Templates in views, viewlets and portlets Any template that is defined as a class-attribute can be overriden using jbot, e.g. those used in views, viewlets and portlets. The template overrides may be registered for any request layer or only a specific layer. CMF objects Any skin-object (e.g. images, templates) on the file system (directory views) can be overridden.
RPMPackage zope-z3c.formwidget.query-0.17-1.lbn25.noarch
This package implements a widget that lets users enter a query and select from the results.
RPMPackage zope-z3c.deadlockdebugger-0.2-3.lbn25.noarch
The z3c.deadlockdebugger package provides a thread debugger. Usage: /debug_threads (requires the 'cmf.ManagePortal' permission) Caution: You should not use this package in production.
RPMPackage zope-z3c.coverage-2.0.3-2.lbn25.noarch
This package contains tools to work with Python coverage data. coveragereport produces HTML reports from coverage data, with syntax-highlighted source code and per-package aggregate numbers. coveragediff compares two sets of coverage reports and reports regressions, that is, increases in the number of untested lines of code.
RPMPackage zope-z3c.checkversions-0.5-1.lbn25.noarch
Find newer versions of your installed Python packages, or newer versions of packages in a buildout file. This package provides a console script named checkversions.
RPMPackage zope-z3c.caching-2.0a1-2.lbn25.noarch
z3c.caching
RPMPackage zope-z3c.blobfile-0.1.5-4.lbn25.noarch
This package provides an implementation of zope.app.file.interfaces.IFile which uses the Blob support introduced in ZODB 3.8. It's main purpose is to provide an easy migration path for existing instances. For more advanced file implementations see zope.file and z3c.extfile. The standard implementation in zope.app.file uses chunk objects to break big files into manageable parts. These chunks flow the server caches whereas blobs are directly consumed by the publisher. The main difference between this blob implementation and the old zope.app.file implementation can be seen in a replacement of the chunk objects by Blobs.
RPMPackage zope-z3c.batching-2.1.0-1.lbn25.noarch
This module implements a simple batching mechanism that allows you to split a large sequence into smaller batches.