Jannis Leidel

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

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

python setup.py develop --uninstall

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/
   

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

One more thing..

One hypothetic idea is to introduce a whole new management command

package

startproject

startapp

package project

package app

package egg

package upload

After creating a Textmate theme based on the colors of djangoproject.com and code.djangoproject.com a while ago, I hereby release:

Download: Django (Smoothy)

UPDATE: Err, wOOOt! My application was today officially accepted by Google and Django’s main developers. Thank you for your support and the confidence you have in me. – Hi. This weblog is about my summer of code 2007. Please look at my curriculum vitae to get to know me better.

My formal application for Google’s Summer of Code is as follows:

Django is one of the major web frameworks that emerged within the last years and created a solid user and developer base. It simplifies the development process by providing tools to reduce repetition, abstracting common web paradigms and still being hackable. Until today that attracted a wide section of programmers, from novices to pros.

As the code base is constantly moving towards the 1.0 release, more and more people are using Django to build small projects and websites, just as well as commercial applications like intranet services and content managment systems are realized with it, too. Good for them:

Reinventing the wheel with Django is perfectly easy – every Django beginner wrote a todo list or weblog applicaton :)

The implementation of a package system would lower the threshold for Django and Python beginners significantly because it reduces the hassle of the current installation procedure.

My task is to do the groundwork for an application which manages Django application packages and integrates tightly with the Django code.

The following steps should illustrate my considerations:

1. Infrastructure (6 weeks)

   Define hooks in the Django code to standardized python modules (e.g. setuptools, distutils, py2exe, py2app etc.) because they solve a lot of software management problems such as dependency tracking and version management. Then implement generic packaging functionality for use via django-admin.py/manage.py: CRUD, upload, download, install package.

Example of a first-time installation of a Django app:

 <strong>tichy:~#</strong> django-admin.py package search Satchmo
    Found 1 package on djangoapps.com:
    1. satchmo - The webshop for perfectionists with deadlines.
<strong>tichy:~#</strong> django-admin.py package install satchmo
    Installation directory for satchmo? [/home/jannis/django/satchmo/]
    Installing satchmo (/home/jannis/django/satchmo/)........Done.
    Syncing sqlite database with initial data...Done.
    Running tests.... 0 errors found.
    Development server is running at http://127.0.0.1:8000/
    Quit the server with CONTROL-C.