Jannis Leidel

I moved my code repository from code.google.com/p/django-package/ to websushi.org/trac/

Please also feel free to test django-package.diff with your Django trunk checkout:

1. wget http://websushi.org/bzr/django-package/django-package.diff
2. cp django-package.diff /path/to/django_src
3. cd /path/to/django_src
4. patch -p0 < django-package.diff

django-admin.py startapp now behaves differently, asking for metadata when creating a new setuptools affine Django application. Editing is done by running django-admin.py editapp in the application directory. The old way of creating “apps” is still valid via django-admin.py startapp --noskeleton.

I also started working on the Django application repository application itself, wondering what Ross is doing at djangoapps.org?

I’m calling for your ideas about the name of the Django application repository:

My proposals:

• djangopackages.com
• djangoapps.com
• djangoapps.org
• djangoapplications.com
• djangocontrib.com
• djangoforge.com
• djangoshop.com
• djangoproject.com/packages/
• djangoproject.com/apps/

just dumping ideas about the realization of a public application repository:

goals:

• central Django application repository
• integration with setuptools via django-admin.py
• easy download and searchable

requirements:

• file management (aka upload)
• community features
• style
• application based (eat your own..)

future:

• Paste hooks
• SVN/Bazaar/.. hooks

implementation:

1. standard setuptools procedures are used to register & upload the release of a django app to the Cheesshop
2. uploaded files have all the same keyword “django.contrib”
3. the homepage URL in the release.py of each django app is a sluggified url to the public repository entry (e.g. http://djangopackages.com/p/django-registration/)
4. a standalone Django application scans periodically the Cheesshop and adds new applications with the keyword “django.contrib” to the repository database (can be cron, signals and/or something else) see: cheeseshop_import.py (cheeserater.com, thanks to Jakob)
5. built with the common django-* application to provide standard community features (now on Google Code):
   django-registration
   django-openid
   django-voting or django-score-voting
   django-tagging
   django-utils
   django-contact-form
   typogrify
   cab (?)
   django-captcha (?)
   django-discussion (?)
   django-profile-images (?)
6. needed models: Package, Owner

questions

• would it make sense to wrap the register and upload process? (e.g. django-admin.py uploadapp)
• encourage BestPracticesToWorkWith3rdPartyAppsAndMakingYoursPortable !/?
• should dependencies be shown in the repository? are owners allowed to pick?
• if needed, what is the best way to administrate the repository editorially?

I’m catching up right now with my Summer of Code project after some horrible exams and have now the time to read the very interesting discussions on the Django developers list.

First, as you may know I wrote some code which changes django.core.management (django-admin.py/manage.py) to ask for basic metadata as soon as the user creates a new django application with “startapp”. The metadata gets stored in a release.py for easy manipulation. A setup.py is also provided to use any functionality of the setuptools.

Unfortunately the problem isn’t just a matter of the actual process of packaging. As pointed out in the discussion about best practices and default application layouts it’s mere the problem of giving the not-so-pro-developers the chance to use pre-built applications without forgetting the needs of the pros.

One proposal was a better documentation of best practices to help beginners understand why “projects” are good to dive into django but are awkward when it comes to distribution and deployment. A great default application scheme was written by Sebastian Macias, even if it confused me a little at first because it imitates Python’s “site-packages”..

I’m sure some of you already have solutions for distribution/deployment because it is obligatory for high traffic sites (or is it?). Server arrangements are pretty cool too, but there must be more. Django applications should be treated like applications not like websites.

Anyway the fact remains: a standard system to manage Django-based modules is required, whether we call them apps, snippets, components, extensions or plugins (think of Wordpress). I proposed to use setuptools even if a lot of people seem to be annoyed about it (why exactly?).

Turbogears and Pylons are using Paste and Setuptools in combination to provide reusability and deployment - considering the different code structure and software strategy a smart decision. Django may need some own handlers to solve the different aspects of this whole topic. Why not rethink the way Django gets deployed?

UPDATE:
You may be interested in reading this: Ian Bicking’s view on the failures of setuptools and python packaging. Well then.. so then just don’t do for Django either? Naah..