I think there are two issues at play here:
1. Separate your site or application into multiple Python projects to
promote re-usability, maintainability, extensibility.
2. Place your packages within a top-level package to prevent
namespace collisions to increase re-usability.
Note there is a different between a "Python project" which is a
directory containing a setup.py file, which can specify one or more
packages or modules belonging to that project and a "Django project"
which is just a Python package intended to drive a Django web site.
Lots of small Python projects is good. Many of the benefits of many
small projects is well espoused by James Bennet in his "Re-usable
Django Apps" talk. You can take this one step farther and apply this
practice of separating individual Django apps into their own Python
projects, and also separate out any non-web or non-Django specific
code and spin it into it's own pure-Python projects. Re-usable Django
apps are basically just plain Python projects that depend upon the
Django project.
If you put all your code inside the foobar top-level package, then you
can re-use other people's Django applications without fear of
namespace collisions. As Tim Peter's famously wrote, "Namespaces are
one honking great idea -- let's do more of those!" However, your own
code will now be within one large source tree as a result of this, and
you may wish to re-use individual sub-packages within your source tree
outside your namespace package (see issue #1). The answer to this
second problem is to use setuptools-based Python projects and take
advantage of the namespace package capabilites of setuptools. This way
you can have your cake and eat it too.
You might have:
* The python project 'FooStory' depends upon 'Django' project and
provides the package 'foobar.story'
* The python project 'FooEvent' depends upon 'Django' project and
provides the package 'foobar.event'
* The python project 'FooCalculator' provides the package
'foobar.calculator'
Laid out on the filesytem this might look like:
my-site-dev-space/
buildout.cfg # states that you are working on a web site that uses
the Python projects: FooStory, FooEvent and FooCalculator
eggs/
foobar.calculator.egg # this project isn't under active
development in the context of my-site-dev-space
src/ # you might use svn:externals to pull these two projects into
here when you checkout my-site-dev-space from svn
FooEvent/
setup.py # info about the FooEvent python project
src/ # source code for the FooEvent project
foo/
event.py
FooStory/
setup.py
src/
foo/
event.py
Now you've achieved goals #1 and #2, but at the added cost of
increased complexity for managing your development environment.
However, these best practices for python project management can be
applied to any Python project, so should you next need to work on a
GUI-based application, or a Plone-based app, or a TurboGears-based
app, etc. you could use these same practices and easily re-use any non-
Django specific packages that you might have developed while working
on your Django-based project.
The recently released "Expert Python Programming" covers a lot of good
ground on these topics (http://www.packtpub.com/expert-python-
programming/book) (esp. chapters 4-7) and does a good job at
documenting many of the current best practices in python project
management.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~----------~----~----~----~------~----~------~--~---
