How to organize the development of a reusable app for Django?

Question

Django

Something I can not think of a folder structure and the development process itself.
The documentation says how to build a package for pypi, but how to make development convenient for the whole team ... So that you can immediately download and install the application for your needs. And at the same time, what could be cloned from the git, run a demo site, fix something, upload it back - here is the new version, which after updating the packages other sites will be able to pull up.
How to organize a package if you need several apps in it?
What other tricks are there for developing reusable-apps? I just came across getmodel. Are there any other goodies?

Answer 1

We actively use our own batteries for Django . Here is a typical structure of one:
scr - the root of the Python package (as for PyPi )
dvhb_docs - the battery itself
testproject - a minimal Django project for testing the battery Setup.py
example :

# -*- coding: utf-8 -*-

import os

from distutils.core import setup

__version__ = "0.1.0"

README = open(os.path.join(os.path.dirname(__file__), 'README.md')).read()
os.chdir(os.path.normpath(os.path.join(os.path.abspath(__file__), os.pardir)))

tests_require = [
    'Django>=1.5',
    'model-mommy',
    'south',
    'pyelasticsearch',
    'elasticsearch',
    'django-haystack>=2.1.0',
    'djangorestframework',
    'django-appconf',
    'webtest',
    'django-webtest',
    'django-celery',
    'django-mptt'
]

setup(
    name='dvhb_docs',
    version=__version__,
    packages=['dvhb_docs'],
    include_package_data=True,
    license='private',
    description='Django application for document store and management.',
    long_description=README,
    url='https://github.com/dvhb/dvhb_docs',
    author='Vadim Lopatyuk',
    author_email='[email protected]',
    classifiers=[
        'Environment :: Web Environment',
        'Framework :: Django',
        'Intended Audience :: Developers',
        'Operating System :: OS Independent',
        'Programming Language :: Python',
        'Programming Language :: Python :: 2.7',
        'Topic :: Internet :: WWW/HTTP',
        'Topic :: Internet :: WWW/HTTP :: Dynamic Content',
    ],
    install_requires=[
        'Django>=1.5',
        'south',
        'pyelasticsearch',
        'elasticsearch',
        'django-haystack>=2.1.0',
        'djangorestframework',
        'django-appconf',
        'django-celery',
        'django-mptt'
    ],
)

MANIFEST.in
requirements.txt the dependency file for the virtual environment is optional (you can include something there for package development, which does not make sense to specify in setup.py ).
By the way, the new (after 1.4) structure of the Django project contributes to the convenient separation of batteries. Those. testproject can be your usual project and at the same directory level there will be modules being developed, which are then deleted and installed from the repository. In the South
migration, you need to make changes to the table snapshot so that there are no conflicts with custom user models. If there are no tricky actions with the user, then a typical version:

{
…
        u'auth.user': {
            'Meta': {'object_name': 'User'},
            'date_joined': ('django.db.models.fields.DateTimeField', [], {'default': 'datetime.datetime.now'}),
            'email': ('django.db.models.fields.EmailField', [], {'max_length': '75', 'blank': 'True'}),
            'first_name': ('django.db.models.fields.CharField', [], {'max_length': '30', 'blank': 'True'}),
            'groups': ('django.db.models.fields.related.ManyToManyField', [], {'symmetrical': 'False', 'related_name': "u'user_set'", 'blank': 'True', 'to': u"orm['auth.Group']"}),
            u'id': ('django.db.models.fields.AutoField', [], {'primary_key': 'True'}),
            'is_active': ('django.db.models.fields.BooleanField', [], {'default': 'True'}),
            'is_staff': ('django.db.models.fields.BooleanField', [], {'default': 'False'}),
            'is_superuser': ('django.db.models.fields.BooleanField', [], {'default': 'False'}),
            'last_login': ('django.db.models.fields.DateTimeField', [], {'default': 'datetime.datetime.now'}),
            'last_name': ('django.db.models.fields.CharField', [], {'max_length': '30', 'blank': 'True'}),
            'password': ('django.db.models.fields.CharField', [], {'max_length': '128'}),
            'user_permissions': ('django.db.models.fields.related.ManyToManyField', [], {'symmetrical': 'False', 'related_name': "u'user_set'", 'blank': 'True', 'to': u"orm['auth.Permission']"}),
            'username': ('django.db.models.fields.CharField', [], {'unique': 'True', 'max_length': '30'})
        }
}

we change to:

from django.conf import settings
…
{
…
        settings.AUTH_USER_MODEL.lower(): {
            'Meta': {'object_name': settings.AUTH_USER_MODEL.split('.')[-1]},
            u'id': ('django.db.models.fields.AutoField', [], {'primary_key': 'True'}),
        }
}

And all sorts of indications of it in the keys of other models like:
on the:
And finally, we put them in this way (now we are working with our own GitLab , but I will give GitHub as an example ):
There are a couple of nuances here:
git+ssh://[email protected]/dvhb/dvhb_docs.git - a link to install a package using pip from git (it differs from the usual link to a turnip for git itself: [email protected]:dvhb /dvhb_docs.git ).
@0.1.0 is a regular tag in a git repository. This way you can install the required version of the package.
#egg=dvhb_docs==0.1.0 is how the package will be presented in the python environment . Those. in this case it will be written as dvhb_docs version 0.1.0 .
At the beginning, we also tried to put the user frontend into the battery, but it changes very much from case to case, as a result, they tied up with this idea and simply began to make common libraries in JS that are installed through Bower (similar to python). The remaining nuances are already added in the project itself.