Django Application Repository

[Mike Cantelon]

Hi all,

My day job is a Drupal developer, but I like the non-magical nature of
Django and have dabbled with it for awhile. I'm working on a
presentation for an upcoming conference on existing pluggable apps for
Django.

Some questions for you guys, as you seem to be working on solidifying
a standard for pluggable apps:

1) Is there a pluggable Django repository? djangoapps.org seems
unused. There is the Django Resources wiki page, but a repository
where pluggable apps could be rated, reviewed, and related would be
super useful (Drupal doesn't have these features in its repository and
it causes a lot of confusion, duplicated effort, etc.).

2) Is there an official guide to making interoperable pluggable apps?
Is the django-reuseableapps project being promoted?

3) Are there other groups other than django-hotclub focussed on
advancing the architecture of, and infrastructure for, Django
pluggable apps?

Thanks in advance for any info!

Cheers,
Mike Cantelon

[flo...@gmail.com]

There are a few efforts that are really going on in tandem here.

1. The Hot Club of France idea is maybe better explained by James
Tauber, but how I understand it is that it's a series of well-tested
reusable apps that follow best-practices, have been vetted, and are
guaranteed to work together. Right now there are a lot of apps in
progress for this grouping of apps, but they are mostly all in the
alpha or beta stages.

2. About 5 of us at the PyCon sprints started work on what will
eventually become djangoapps.net. There is an old version up there
right now (please don't put too much weight into what's up there now,
it'll be getting a major overhaul on our public release). The idea
behind it is not to create a repository, like you mentioned, but
rather an index. We feel that google code, sourceforge, and
individual trac instances are much better at that task. Instead, the
real problem is duplication of effort and choosing which solution is
right. That's what djangoapps.net will be--a way to search for,
submit, rate, and comment on different reusable Django applications.
We hope to be completed with this project soon, but real lives
continue to get in the way. Head over to http://djangoapps.net/trac/
to see the code and the timeline, etc.

3. I really don't know much about django-reusableapps. I know that it
was created by Jannis Leidel (someone who has been involved in django-
hotclub and djangoapps.net, and you might want to get in contact with
him) at a time when Django was less extendable. Is it being actively
promoted? I think mostly it's being promoted by Jannis, but other than
from him I haven't heard any buzz.

4. There are no standards or guidelines, and therefore there are no
HOWTI guides. I have just brought up the lack of guide as part of the
documentation restructuring process, and if nobody else takes on that
responsibility, I may very well volunteer to write such a guide.
Standards are, however, emerging and a guide could easily be written
documenting them. One thing that might help to make this process
easier is the fact that the INSTALLED_APPS list will start to allow
for metadata to be passed in alongside the application name. How this
metadata is used to further the state of reusable apps remains to be
seen, but I can't imagine that reusable app writing will stay quite
the same after that change.

Hopefully I've answered your questions!

Thanks,
Eric Florenzano

[Ross Poulton]

I will quickly weigh into this:

I have registered a domain http://djangoapps.org/ and have begun
building a simple application index. Similar to the ideas above, it's
an index rather than a repository.

From the start I have had this site integrated with my other community
site, www.djangosites.org - so users only have to sign up once to use
both sites. I have discussed with others the possibility of merging
their Django community sites (by way of shared databases) to close the
gap between the different sites even further.

Before either I or Eric go much further, perhaps we can look at
working together as there is no need for two application indexes. I
think using the existing userbase is a great idea, as the sheer number
of logins people now have for different Django community sites is
growing rapidly.

If you wish to take this off-list for now, feel free to contact me at
my first name at rossp.org.

Cheers,

Ross Poulton
www.rossp.org
www.djangosites.org

[Mike Cantelon]

> 4. There are no standards or guidelines, and therefore there are no
> HOWTI guides. I have just brought up the lack of guide as part of the
> documentation restructuring process, and if nobody else takes on that
> responsibility, I may very well volunteer to write such a guide.
> Standards are, however, emerging and a guide could easily be written
> documenting them. One thing that might help to make this process
> easier is the fact that the INSTALLED_APPS list will start to allow
> for metadata to be passed in alongside the application name. How this
> metadata is used to further the state of reusable apps remains to be
> seen, but I can't imagine that reusable app writing will stay quite
> the same after that change.

Hi Eric,

Thanks for getting me up to speed! That was very useful!

Cheers,
Mike

[Jannis Leidel]

Hi all,

Thanks guys for bringing this up here. This is what I know about the
topic:

At my last year's Google Summer of Code project I worked on making
Django apps easier to use. One result was the django-package project
[1] that changes the way the 'startapp' command works, adds an
'editapp' command and uses setuptools with (I think) nifty functions
to provide metadata. This is for the most part obsolete now of course,
partly because Adrian changed the API a week before the deadline,
partly because of my later django-reusableapps app and partly because
of the redesign of INSTALLED_APPS and the app loading mechanism that
was discussed at Pycon (as mentioned by Eric) that will make it much
easier to hook into Django. For me this simple design decision was
worth the trip to Chicago :)

The django-reusableapps app is caught between two stools at the
moment. As far as I know it still works for the current trunk und I
use it in several projects myself. setuptools is a great way to track
dependencies and makes automatic installation a piece of a cake.
Especially the '--index-url' option of easy_install is convenient. But
I also hear the mumble in the Python community (remember Zed Shaw's
easy_fucking_uninstall [2]) and sensed no real will at the Pycon
sprint to re-add setuptools support to Django core. Though that might
change once setuptools merge with distutils. Anyway I'm willing to
support django-reusableapps in the future, making it a bridge between
setuptools/distutils and Django's own metadata functionality. For
example the new django.core.managment module makes it easy to create a
'package' command that builds eggs from a reusable app. Feel free to
ask me for access to the Google Code project.

As Eric already said we worked hard on an app index at djangoapps.net
which I intially registered to host my Summer of Code results. As you
can see in the code at http://djangoapps.net/trac/ it's fairly done
and only needs some finishing touches to be released. Integration with
djangosites.org sounds interesting but IMO should be done by providing
an API or similiar. Having OpenID integration in djangoapps.net makes
it very easy for users to recommend, bookmark or comment on apps.

Cheers,
Jannis

1: http://code.google.com/p/django-package/
2: http://www.zedshaw.com/blog/2008-03-16.html

[Mike Cantelon]

> From the start I have had this site integrated with my other community
> site, www.djangosites.org - so users only have to sign up once to use
> both sites. I have discussed with others the possibility of merging
> their Django community sites (by way of shared databases) to close the
> gap between the different sites even further.

Hi Ross,

Good idea. Opening up community-driven application metadata via shared
databases or an API would be very useful.

> Before either I or Eric go much further, perhaps we can look at
> working together as there is no need for two application indexes. I
> think using the existing userbase is a great idea, as the sheer number
> of logins people now have for different Django community sites is
> growing rapidly.

Yes, minimizing duplication of effort is ideal.

Someday seeing the app index integrated into the mothership at
apps.djangoproject.com would be another interesting possibility.

Cheers,
Mike

[Mike Cantelon]

> For me this simple design decision was
> worth the trip to Chicago :)

Excellent!

> change once setuptools merge with distutils. Anyway I'm willing to
> support django-reusableapps in the future, making it a bridge between
> setuptools/distutils and Django's own metadata functionality. For
> example the new django.core.managment module makes it easy to create a
> 'package' command that builds eggs from a reusable app. Feel free to
> ask me for access to the Google Code project.

Thanks Jannis! This sounds very promising... I'll check it out further.

Cheers,
Mike