semvec/pypi-packages huggingface dataset:
dj.paste 1.14
Yet another WSGI Paste factory for paste sponsored by Makina Corpus
License: BSD

Introduction
============

Yet another `paste`_ factories for django

.. _paste: http://pythonpaste.org/

.. contents::

Makina Corpus sponsored software
======================================
|makinacom|_

* `Planet Makina Corpus <http://www.makina-corpus.org>`_
* `Contact us <mailto:python@makina-corpus.org>`_

.. |makinacom| image:: http://depot.makina-corpus.org/public/logo.gif
.. _makinacom:  http://www.makina-corpus.com



What is dj.paste
==================

It is just another `PythonPaste applications`_ wsgi wrappers:

.. _PythonPaste applications: http://pythonpaste.org/deploy/#paste-app-factory

    * ``dj.paste#mono`` or only ``dj.paste``:
        A paste factory to use when you have only one django on your instance

    * ``dj.paste#multi``
        A paste factory to use when you have more than one django on your instance 
        but be careful that there is a fakeDjangoModule trick that can lead to problems (not seen so far)


How to use dj.paste
=====================

Django App
----------------
With paste, just add another app entry with a django_settings_module  variable to point to
your django settings ::

    [composite:main]
    use = egg:Paste#urlmap
    / = foo

    [app:foo]
    use=egg:dj.paste
    django_settings_module=foo.settings 

django factory
-----------------------------------------

Checking that everything is in place::

    >>> resp = app.get('/')
    >>> 'first django' in resp.body.lower()
    True



Changelog
=========

1.14 (2012-02-22)
-----------------
- add weberror wrapper

1.10 (2012-02-22)
-----------------
* proper release

1.8
---------
* add a mono factory (and now the default)
* cleanup


1.3 - 1.4
----------

* fix multiple djangos in the same paste instance

1.2
-----

* fix script_path, see http://code.djangoproject.com/ticket/1516

1.0 
----------------
* Initial release
django-albertson 0.1.1
Integration library for Django and Albertson.
License: BSD

================
django-albertson
================

Homepage:  https://github.com/FocusLab/django-albertson

Integration library for Django and `Albertson <https://github.com/FocusLab/Albertson>`_.

---
Use
---

DjangoSettingsMixin
===================

`dj_albertson.mixins.DjangoSettingsMixin`

This mixin provides automatic loading of default settings for a CounterPool
from the django settings module.

Below is an example use::

    from albertson import CounterPool
    from dj_albertson.mixins import DjangoSettingsMixin

    class MyCounter(DjangoSettingsMixin, CounterPool):
        '''
        That's it, your done!
        '''

Once you've added this mixin to your counter pool classes, the following
settings will be used:

ALBERTSON_AWS_ACCESS_KEY
    The AWS access key id that will be used to access DynamoDB.  This is the
    setting that will be used if both `AWS_ACCESS_KEY_ID` and
    `ALBERTSON_AWS_ACCESS_KEY` are provided.

ALBERTSON_AWS_SECRET_KEY
    The AWS secet key that will be used to access DynamoDB.  This is the
    setting that will be used if both `AWS_SECRET_ACCESS_KEY` and
    `ALBERTSON_AWS_SECRET_KEY` are provided.

AWS_ACCESS_KEY_ID
    A more generic form of `ALBERTSON_AWS_ACCESS_KEY`

AWS_SECRET_ACCESS_KEY
    A more generic form of `ALBERTSON_AWS_SECRET_KEY`

ALBERTSON_DEFAULT_READ_UNITS
    The default read throughput that will be set on newly created tables.

    **default:** 3

ALBERTSON_DEFAULT_WRITE_UNITS
    The default write throughput that will be set on newly created tables.

    **default:** 5

ALBERTSON_AUTO_CREATE_TABLE
    A flag to control how Albertson should behave when it tries to use a
    table that doesn't exist.  If set to `True`, Albertson will create a new
    table.  If set to `False`, Albertson will allow the underlying boto
    exception to bubble up through the stack.

    **default:** True
django-live-server 0.1.2
Implementation of the LiveServerTestCase code due out in Django 1.4
License: BSD

Django Live Server
==================

This is purely the implementation of the ``LiveServerTestCase`` code 
due out in Django 1.4. 

Details are here:

https://docs.djangoproject.com/en/dev/releases/1.4/#support-for-in-browser-testing-frameworks
https://code.djangoproject.com/changeset/17241

I make no claim at all to this code - it was written by people 
much smarter than I!
gitrecipe 0.0.2
Simple buildout recipe for downloading git repositories. It uses system git command and its syntax
License: BSD
Keywords: git recipe buildout zc.buildout

Welcome to gitrecipe doc page

Usage
-----

Recipe clones git repository and checkouts to revision, if it is provided 
in configuration. You can use recipe like this: ::

    [buildout]
    parts = data
    
    [data]
    recipe = gitrecipe
    repository = git://example.com/my-git-repo.git
    rev = origin/redevlop-branch

Options
-------

*repository* - repository url

*ref* of *rev* - git reference_ wich you want to checkout

Notes
`````

*rev* option leaved for compatibility with ``zerokspot.recipe.git``.
It is better to use *ref* parameter, because it corresponds Git terminology

Since 0.0.2 recipe does check existing repository while install and update.
Repository origin url must be the same as given in **rev** option.
Otherwise repository will be deleted and cloned again.


About
-----

I've used recipe ``zerokspot.recipe.git``, but as for me, it too complex and has some disadvantages:

- it does not allow commit from the source folder, default remote is local copy in downloads
- it does not allow to specify the tag or branch of the repository, only revision hash

So I wrote my own git recipe with compatible options. You can choose this or that.


.. _PYPI: http://pypi.python.org/pypi
.. _reference: http://book.git-scm.com/7_git_references.html
django-orm 2.0.5
Advanced improvement of django-orm with a lot of third-party plugins for use different parts of databases are
not covered by the standard orm.
License: BSD

Currently the only supported what was django-postgresql. 
But I'm working for some features available for all supported backends (postgresql, sqlite,
mysql), as orm connection-pool and low-level cache.

If you want to know in detail what it offers for each database, check the documentation.

* **Documentation**: http://readthedocs.org/docs/django-orm/en/latest/
* **Project page**: http://www.niwi.be/post/project-django-orm/