← May June July →

Update on my GSoC project: django-package

Here is the first update on my Google Summer of Code 2007 project-a simple rip-off of my mail to the developer list. Here you can find the new django-package project with the current patch:

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
.

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/
The new workflow

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 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.. (more) 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 more thing..

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!

Google Summer of Code June 25, 2007, 5:50 p.m. comments (0)

Lifefeed