Log message:
py-dogpile-cache: updated to 0.9.2

0.9.2:
[bug] [installation]
Ensured that the “pyproject.toml” file is not included in builds, as the \ 
presence of this file indicates to pip that a pep-517 installation process \ 
should be used. As this mode of operation appears to be not well supported by \ 
current tools / distros, these problems are avoided within the scope of \ 
dogpile.cache installation by omitting the file.

0.9.1:
[bug] [tests]
Added decorator module as a required testing dependency to tox.ini so that tests \ 
work when this is not pre-installed.

[bug] [redis]
Added option to the Redis backend RedisBackend.thread_local_lock, which when set \ 
to False will disable the use of a threading local by the redis module in its \ 
distributed lock service, which is known to interfere with the lock’s behavior \ 
when used in an “async” use case, within dogpile this would be when using \ 
the CacheRegion.async_creation_runner feature. The default is conservatively \ 
being left at True, but it’s likely this should be set to False in all cases, \ 
so a warning is emitted if this flag is not set to False in conjunction with the \ 
distributed lock. Added an optional argument to RedisBackend that specifies \ 
whether or not a thread-local Redis lock should be used. This is the default, \ 
but it breaks asynchronous runner compatibility.

0.9.0:
[feature]
Added logging facililities into CacheRegion, to indicate key events such as \ 
cache keys missing or regeneration of values. As these can be very high volume \ 
log messages, logging.DEBUG is used as the log level for the events. Pull \ 
request courtesy Stéphane Brunner.

0.8.0:
[bug] [setup]
Removed the “python setup.py test” feature in favor of a straight run of \ 
“tox”. Per Pypa / pytest developers, “setup.py” commands are in general \ 
headed towards deprecation in favor of tox. The tox.ini script has been updated \ 
such that running “tox” with no arguments will perform a single run of the \ 
test suite against the default installed Python interpreter.

[bug] [py3k]
Replaced the Python compatbility routines for getfullargspec() with a fully \ 
vendored version from Python 3.3. Originally, Python was emitting deprecation \ 
warnings for this function in Python 3.8 alphas. While this change was reverted, \ 
it was observed that Python 3 implementations for getfullargspec() are an order \ 
of magnitude slower as of the 3.4 series where it was rewritten against \ 
Signature. While Python plans to improve upon this situation, SQLAlchemy \ 
projects for now are using a simple replacement to avoid any future issues.

[bug] [installation]
Pinned minimum version of Python decorator module at 4.0.0 (July, 2015) as \ 
previous versions don’t provide the API that dogpile is using.

[bug] [py3k]
Fixed the sha1_mangle_key() key mangler to coerce incoming Unicode objects into \ 
bytes as is required by the Py3k version of this function.

Log message:
py-dogpile-cache: updated to 0.7.1

0.7.1
[bug] [region] Fixed regression in 0.7.0 caused by 136 where the assumed \ 
arguments for the CacheRegion.async_creation_runner expanded to include the new \ 
CacheRegion.get_or_create.creator_args parameter, as it was not tested that the \ 
async runner would be implicitly called with these arguments when the \ 
CacheRegion.cache_on_arguments() decorator was used. The exact signature of \ 
async_creation_runner is now restored to have the same arguments in all cases.

0.7.0

[bug] The decorator module is now used when creating function decorators within \ 
CacheRegion.cache_on_arguments() and CacheRegion.cache_multi_on_arguments() so \ 
that function signatures are preserved. Pull request courtesy ankitpatel96.

Additionally adds a small performance enhancement which is to avoid internally \ 
creating a @wraps() decorator for the creator function on every get operation, \ 
by allowing the arguments to the creator be passed separately to \ 
CacheRegion.get_or_create().

[bug] [py3k] Fixed all Python 3.x deprecation warnings including inspect.getargspec()

Log message:
py-dogpile-cache: updated to 0.6.7

0.6.7:
[bug] Fixed issue in the CacheRegion.get_or_create_multi() method which was \ 
erroneously considering the cached value as the timestamp field if the \ 
CacheRegion.invalidate() method had ben used, usually causing a TypeError to \ 
occur, or in less frequent cases an invalid result for whether or not the cached \ 
value was invalid, leading to excessive caching or regeneration. The issue was a \ 
regression caused by an implementation issue in the pluggable invalidation \ 
feature added in 38.

0.6.6:
[feature] Added method CacheRegion.actual_backend which calculates and caches \ 
the actual backend for the region, which may be abstracted by the use of one or \ 
more ProxyBackend subclasses.
[bug] Fixed a condition in the Lock where the “get” function could be called \ 
a second time unnecessarily, when returning an existing, expired value from the \ 
cache.

0.6.5:
[bug] Fixed import issue for Python 3.7 where several variables named \ 
“async” were, leading to syntax errors. Pull request courtesy Brian Sheldon.

Log message:
py-dogpile-cache: update to 0.6.4

0.6.4

[bug] The method Region.get_or_create_multi() will not pass to the cache backend \ 
if no values are ultimately to be stored, based on the use of the \ 
Region.get_or_create_multi.should_cache_fn function. This empty dictionary is \ 
unnecessary and can cause API problems for backends like that of Redis. Pull \ 
request courtesy Tobias Sauerwein.

[bug] The api.NO_VALUE constant now has a fixed __repr__() output, so that \ 
scenarios where this constant’s string value ends up being used as a cache key \ 
do not create multiple values. Pull request courtesy Paul Brown.

[bug] A new exception class exception.PluginNotFound is now raised when a \ 
particular cache plugin class cannot be located either as a setuptools \ 
entrypoint or as a registered backend. Previously, a plain Exception was thrown. \ 
Pull request courtesy Jamie Lennox.

Log message:
Import py-dogpile-cache-0.6.2 as devel/py-dogpile-cache

Dogpile consists of two subsystems, one building on top of the other.

dogpile provides the concept of a "dogpile lock", a control structure which
allows a single thread of execution to be selected as the "creator" of some
resource, while allowing other threads of execution to refer to the previous
version of this resource as the creation proceeds; if there is no previous
version, then those threads block until the object is available.

dogpile.cache is a caching API which provides a generic interface to caching
backends of any variety, and additionally provides API hooks which integrate
these cache backends with the locking mechanism of dogpile.

Overall, dogpile.cache is intended as a replacement to the Beaker caching
system, the internals of which are written by the same author. All the ideas of
Beaker which "work" are re- implemented in dogpile.cache in a more \ 
efficient and
succinct manner, and all the cruft (Beaker's internals were first written in
2005) relegated to the trash heap.