> I would suggest rather saving the information into a file like
> release.py, and using execfile in setup.py to read the information.
> (Also, it should be easier for you to read the config back in again.)
This is a rather good idea which I implemented here at the new django-
For now the patch adds a command line switch to the startapp command
# 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:
When introducing something like package management we also have to
think about changing the workflow.
3. development and testing
4. semi-automatic deployment
1. startapp (with package skeleton and meta information)
2. develop application and test with "python setup.py develop"
3. egg deployment  with "python setup.py bdist_egg" and
Generic applications like django-registration, django-tagging, django-
voting, django-utils, django-contact-form, django-forum..  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!