Source: beaker
Maintainer: Debian Python Team <team+python@tracker.debian.org>
Uploaders: Piotr Ożarowski <piotr@debian.org>
Section: python
Testsuite: autopkgtest-pkg-python
Priority: optional
Build-Depends: debhelper-compat (= 13)
Build-Depends-Indep: dh-sequence-python3,
                     python3-all,
                     python3-setuptools,
                     python3-sqlalchemy <!nocheck>,
                     python3-webtest <!nocheck>,
                     python3-pycryptodome (>= 3.20) <!nocheck>,
                     python3-pylibmc | python3-memcache <!nocheck>,
                     python3-pymongo <!nocheck>,
                     python3-redis <!nocheck>
Standards-Version: 4.6.2
Vcs-Browser: https://salsa.debian.org/python-team/packages/beaker
Vcs-Git: https://salsa.debian.org/python-team/packages/beaker.git
Homepage: https://beaker.readthedocs.io
Rules-Requires-Root: no

Package: python3-beaker
Architecture: all
Depends: ${python3:Depends},
         ${misc:Depends}
Recommends: ${python3:Recommends},
            python3-pkg-resources
Suggests: ${python3:Suggests},
          python3-sqlalchemy,
          python3-pycryptodome (>= 3.20),
          python3-pylibmc | python3-memcache,
          python3-pymongo,
          python3-redis
Description: cache and session library for Python 3
 Beaker is a web session and general caching library that includes WSGI
 middleware for use in web applications.
 .
 As a general caching library, Beaker can handle storing for various times any
 Python object that can be pickled with optional back-ends on a fine-grained
 basis.
 .
 Features:
  * Fast, robust performance
  * Multiple reader/single writer lock system to avoid duplicate simultaneous
    cache creation
  * Cache back-ends include dbm, file, memory, memcached, and database (using
    SQLAlchemy for multiple-db vendor support)
  * Signed cookies to prevent session hijacking/spoofing
  * Cookie-only sessions to remove the need for a database or file backend
    (ideal for clustered systems)
  * Extensible Container object to support new back-ends
  * Caches can be divided into namespaces (to represent templates, objects,
    etc.) then keyed for different copies
  * Create functions for automatic call-backs to create new cache copies after
    expiration
  * Fine-grained toggling of back-ends, keys, and expiration per Cache object