Hi,
After the official end on monday and two weeks without a real status
update on my GSoC project I'd like to share some thoughts and ideas
that came up during the summer. As a spoiler (or if you don't feel
like reading the big chunk of text below): I have not completed all of
my original project goals but will continue to work.
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.
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.
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.
To facilitate the preparation of apps I added hooks to
dango.core.management (the refactored code too) to ask for the
metadata with "startapp" and made it the default (--noskeleton for the
current behaviour). It also creates skeleton files, builds a MANIFEST
file and gives the option to edit the release information later
("editapp"). The prepared apps can be uploaded to the PyPI or use
virtually any other function of setuptools. [2] (django.utils.package)
In the second part of my project I needed to bridge the gap between
the reusable Django apps and a to-be repository. Since I already used
setuptools (and PyPI) to create application packages, I decided to add
a keyword to any app (e.g. "django.apps") which later can be used to
identify the packages during a PyPI scan. With a little inspiration by
Jacob's project cheeserater.com I got this scan working in the days
before final evaluation. [3]
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?
James, thanks for your support and constant patience, I really learned
a lot this summer about programming and this crazy open source thing.
Seriously, you got one contributer more.
All the others, if you find the time, please have a look at my code
[2] and tell me if this all makes sense. My weblog [4] has some more
information about my summer of code, too.
Best
Jannis
1: http://jannisleidel.com/2007/03/gsoc-application/
2: http://code.google.com/p/django-package/
3: http://websushi.org/trac/browser/django-apps/
4: http://jannisleidel.com
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
