My current idea of packaging django apps is to provide several  
options for the command line management (manage.py/django-admin.py)  
to generate, edit and execute setuptools' native packaging  
functionality via the quasi-standard files "setup.py".

The unobtrusive use of setuptools' "bdist_egg" command would create a  
standalone application package, enabled to live anywhere on the  
python path. Of course any other setuptools command [1] is available,  
too. E.g. installation via "easy_install myapp-0.1.egg", registration/
upload to pypi [2] and distribution as a source package.

If you decide to fill in package information, you get asked for every  
required information [3] but can add more manually to setup.py.

1. This is how it might look like when you start a new application:

# django-admin.py startapp --package myapp
Do you want to fill in package information now? (yes/no) yes
Version: 0.1
Description: This is an example application.
Author name: Jannis Leidel
Author e-mail address: jan...@leidel.info
Package URL: http://whatever.tld/myapp
Generating application skeleton and setup.py... done
# ls
docs/     MANIFEST    myapp/    setup.py    tests/
# ls myapp
__init__.py models.py   templates/  urls.py   views.py

2. Adding package information to an existing application and editing  
the information of an app created by "startapp":

# django-admin.py package myapp
Package Name (Leave blank to use myapp): blog
Version (0.1): 0.2
Description: This is the same application, now a blog.
Author name (Jannis Leidel): Jannis Leidel & friends
Author e-mail address (jan...@leidel.info):
Package URL (http://whatever.tls/myapp): http://another.tld/blog
Generating application skeleton and setup.py... done
# ls
docs/     MANIFEST    blog/    setup.py    tests/
# ls blog
__init__.py models.py   templates/  urls.py   views.py

3. Packaging the blog application:

# python setup.py bdist_egg
..
# ls dist/
blog-0.2-py2.4.egg

4. Installation:

# easy_install dist/blog-0.2-py2.4.egg
..
Processing dependencies for blog==0.2
Finished processing dependencies for blog==0.2

My task for the week is to develop the "--package" switch, ask the  
meta information questions and put this into a setup.py file. I don't  
know if this is the "right" interface to packaging but this would not  
force developers into packaging all their apps and still makes it  
possible to use advanced packaging functionality by editing setup.py  
manually.

Anyway it would be very nice to hear your comments since this can be  
very useful when it comes to deployment. What is your idea of a  
useful interface to packaging? Could you imagine using this on a  
daily basis?

Best,
Jannis

1: http://peak.telecommunity.com/DevCenter/setuptools#command-reference
2: http://www.python.org/pypi
3: http://docs.python.org/dist/meta-data.html

That way people can control their setup.py to quite some degree if
they want to move off the default, but can still use the tool to
handle other stuff.  And they can hand-edit the release.py without any
bad side-effects.

Neil
--
Neil Blakey-Milner
http://nxsy.org/
n...@nxsy.org

http://code.google.com/p/django-package/

For now the patch adds a command line switch to the startapp command  
of django.core.management:
# django-admin.py --package startapp myapp
which asks for the meta information required for packaging. Please  
try it out!

It creates a basic skeleton application in the current directory,  
ready to be used by setuptools.
For testing purposes you can use setuptools standard functions like  
running "python setup.py develop" to add it to the python path,  
uninstalling with "python setup.py develop --uninstall" or wrapping  
it in an egg file with "python setup.py bdist_egg".

****
Concerning the application skeleton:

I would like to collect some of your ideas about the common file  
names and directories which should be created by default. This is  
also needed when it comes to packaging non-python files like template  
html-files, sql-files and so on. What are the common filenames? How  
do you manage your django projects?

As suggested by Neil there is already a release.py for easier  
manipulation of the meta data.
The current code creates this:

# ls
MANIFEST.in
docs/
release.py
setup.py
test/
myapp
myapp/templates/

****
When introducing something like package management we also have to  
think about changing the workflow.

Current workflow:
1. startproject
2. startapp
3. development and testing
4. semi-automatic deployment

Proposed workflow:
1. startapp (with package skeleton and meta information)
2. develop application and test with "python setup.py develop"
3. egg deployment [1] with "python setup.py bdist_egg" and  
"easy_install myapp-0.1.egg"

Generic applications like django-registration, django-tagging, django-
voting, django-utils, django-contact-form, django-forum.. [2] can be  
installed system wide and therefore live on the python path (in  
python's standard site-packages directory).

I'd like to encourage new developers to follow my workflow proposal  
as it makes development, packaging and deployment much easier.

Hence I suggest making it the default behaviour of "startapp" to  
create standalone packages, while requiring a command-line switch to  
create an application without the skeleton files (the current  
"develop inside a project" style, like in the tutorials).

****
One hypothetic idea is to introduce a whole new management command  
"package" to wrap most of the current functions like "startproject",  
"startapp" and the ideas before. This would wrap some of setuptools  
functions and could have a feature-set like: "package project",  
"package app", "package egg", "package upload" and so on. I actually  
do think this is evil since it wraps functions of setuptools but your  
mileage may vary. Tell me what you think!

Best,
Jannis

1: http://peak.telecommunity.com/DevCenter/PythonEggs
2: http://code.google.com/hosting/search?q=django