There is a list of all Python-based build tools on the python.org wiki: http://wiki.python.org/moin/ConfigurationAndBuildTools
I haven't used any of them with Django, but for managing Zope, Plone and Grok based web apps, zc.buildout is the current preferred tool. It's a configuration-based build tool (that is it decides to re-build parts based on changes in the build config files), so it won't handle the problem of source code recompilation very well, but then if your project is pure Python, source code recompilation is not a problem :) zc.buildout shines in two aspects: * Managing Python library dependencies Zope 2 (and Zope 3) used to be distributed from a single source tree. This was a problem, because it made it hard to share packages between the various Zope-based projects, and other Python web apps. Zope 3 was divided into some 80+ packages, new releases of Zope 3 are now just a list of these packages at specific versions. Very nice when upgrading the framework because you diff between two releases of the framework and see which packages have changed - and you can also override this list if you want to pin a packages version at something older or newer than what's been included in a given release. This also makes it really great at managing 3rd party libraries such as SQLAlchemy, etc. * Sharing recipes between builds zc.buildout recipes can be Python code that is part of your own project, or a recipe can be published on PyPI. This way if someone else is maintaining a recipe to build a part that you'd like to include in your project, you can easily re-use their recipe (without using cut-n-paste re-use). Buildout recipes on PyPI are here: http://pypi.python.org/pypi?:action=browse&show=all&c=512 As for the specific build use cases you mention: > * run unit tests There are buildout recipes for creating testrunners (http:// pypi.python.org/pypi/zc.recipe.testrunner/1.1.0). This will create a ./ bin/test script in your project to run test suites. > * copy files to a distribution set based on a target (production, > staging, clustered, etc.) By default, a project will have a buildout config file named buildout.cfg in the root directory. This file can inherit from other build config files, so you can have a base.cfg, production.cfg and development.cfg. I usually include things such as PyLint in the dev build, and specific ports and passwords in the production.cfg file. Buildout doesn't do remote execution, e.g. if you want to be able to update production servers from your dev workstation like Rails devs do with Capistrano. > * include config files specific to the target, and not including > source control files and other development > time artifacts. Again, generally solved by having dev.cfg and production.cfg files containing differences between the environments. And again, if you have problems such as conditional header files and source code compilation for multiple target platforms, buildout is probably going to be the wrong tool. > * transfer distribution Dunno what this means? Be warned that while buildout is very lovely when your web app begins to use more and more 3rd party projects, or has an increasingly complex set of parts - it's awesome to add a couple packages to the list of eggs used by a project and ask another developer to "svn up; ./ bin/buildout" and they get the same library set installed as you have in your dev environment - but the introductory documentation for buildout is still somewhat ... lacking. > > Perhaps you just hand build python scripts to do it. Or do you use > Ant or make? I'm coming over from Java, and used to use Ant, but I'm > migrating over to Python and would like to use what is generally > considered the Pythonic way. > Python doesn't have an equivalent of Ant/Java as far as a certain build tool being more predominantly used. Generally most of the current crop of Python build tools are fairly young so you'll find rough edges on all of the projects (with the exception of SCons I think, although that's mostly a source code recompiliation build tool). Most of the build tool interested folks are subscribed to the distutils-sig mailing list, so it's a good place to ask more questions: http://www.python.org/community/sigs/current/distutils-sig/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
