-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Jannis, Thanks for your time writing this post. :) I like this idea of having reusable apps for Django all in the same place. Here's some suggestions. > My initial GSoC application [1] was divided in: > > 1) Create code infrastructure to simplify the process of building > reusable Django applications, e.g. with egg files. > 2) Build a public repository website for reusable Django applications. Egg files are great. We could easy_install them, assuming the user or developer is already using setuptools. > Even if these two topics are connected in a way, I stumbled over the > rather different approaches to package management on a programming > language, operating system and community level. I evaluated the > package formats I knew to learn more about common package management > idioms (apt, rpm, gems, distutils, setuptools) and realized that > reinventing the wheel should be avoided - especially for a specific > product like Django; reusable Django apps should happen with something > stable and widely known, preferable without having to tie users to a > "simple", wrapped version of a sophisticated system. Agreed. In order to distribute reusable django apps, there should be at least a common package namespace where all theses packages would get installed. I've thought the namespace "apps" would be a good starting point for this. > So, giving the user the option to have an easy start with package > management was my first actual goal. I looked at the standard > distutils and the defacto standard setuptools and found the features I > needed: package management, dependency tracking, uploading and an easy- > to-distribute format - eggs. Hacking the setuptools code and cloning > the cheeseshop (PyPI) wasn't an option of course, so instead I > introduced a "release" metaphor (thanks for the idea Neil Blakey- > Milner) which holds the basic metadata for a reusable Django > application. It's basically a simple Python file which lives in the > application directory, gets loaded by setup.py and can be hand-edited > or even abandoned if not needed. Again, I really like the idea to use setuptools and eggs for distribution of django apps/packages. However, Im less sure about adding anything special inside a app for specifying metadata. Why not just use a regular setup.py script for distributing a standalone app ? > So now I'm on building the rest of the repository website, using > several of the django-* Google Code projects. If you have any ideas > for it, feel free to contact me. What about djangoapps.org? +1 for djangoapps.org and for using a common package namespace for reusable django apps. [apps] Also, the freebsd ports collection is a great example of a well-managed collection of reusable apps. We should use this more for inspiration.. :) Finally, please check out notmm. Its a Django toolkit containing various packages, and a set of django apps (distributed as a standalone component, but included in the standard distribution). [1] 1. svn co http://tools.assembla.com/svn/notmm/trunk/ notmm Cheers, - - Etienne -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.5 (FreeBSD) iEYEARECAAYFAkbS2/wACgkQdXKAffkXj4OeTgCfSoiattnF4JoHChUvLqYoP4c7 QrgAoLDZcClKCDj83MEXz+Ngo0gL/PhS =kk87 -----END PGP SIGNATURE----- --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
