GSoC: packaging Django applications
Jannis Leidel
Here is the not-so-weekly update on my Google Summer of Code project:
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
Neil Blakey-Milner
> 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.
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.)
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
Jannis Leidel
> 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-
package project:
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