> For the configuration part, it would be nice if buildout had better > tools to help you back out of problems or avoid them. For example, a > dry-run option that told you what would be changed by running buildout > would be nice. >
how about building just one part (or even building it to a tmp directory and moving on success) eg. lxml I didn't know this would fail, it worked on OS X ./bin/buildout -c live.cfg -build-egg lxml ./bin/buildout -c live.cfg -build-part libevent this would fetch and build just that egg/part and we could watch it fail or succeed before proceeding and doing the whole buildout that is supposed to use this new egg. also then an actual deploy wouldn't have to wait for compiling etc. which shouldn't happen during a live-server deploy caveat: its not harmless if its a rebuild of something in use or the egg will kick another egg out of the nest also: if the part triggers other existing dependencies then they will get built. dry run to a different buildout directory also sounds good, and probably not to tricky to do. thanks very much for your time jim ! and for buildout, I've been using it for about 6 months and the server configs are much more sane now. django-celery-rabbitmq-memcached-nginx-apache-supervisor many many eggs, plus scripts for server checking, cron jobs etc. its unmanageable without buildout > Jim > > -- > Jim Fulton >
_______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
