> > I think db schema migration should wait until django has some > > feature that supports it, a limited set of scripting (python itself > > of course) should be allowed in the "recipes"
I will take note of that. I thought that I'd leave that bit for the end anyways. The bit about the "recipes" is a good idea. Make up a "cooking book" of standard stuff and let people put it together, like "update from svn, update postgresql database from sql file, restart nginx", and leave space for them to plug in custom stuff. Sounds like a good start. El lun, 10-09-2007 a las 20:50 -0300, qwerty escribi�: > "recipes" is capistrano nomenclature, how should be called in this new > project? "jobs", or "tasks" is a good way to go. > > I think that a good way to go is first define a set of servers, each > one with differents services, and define a global service->task > relation. > Then a per-server relation if special jobs are needed in each one, > this way we can make a "task" able to clear memcache, other task > restarting lighttpd, etc in different servers, yaml looks like a good > option for this configuration, or something parseable by ConfigParser > sounds better? > > 2007/9/10, David Reynolds <[EMAIL PROTECTED]>: > > > On 10 Sep 2007, at 4:13 pm, Chris Hoeppner wrote: > > > I see your point. Why reinvent the wheel? True. But I'm not > trying to > > re-do capistrano using python instead of ruby. Capistrano > has been the > > spark that made me think about doing this, but that's all > there is to > > Capistrano. > > > > I'm doing this because: > > > > 1) I've anyways been thinking about this for ages. > > > > 2) I'd love to "djangostrano.py publish" or "djangostrano.py > > update-remote". > > > > 3) What about rails' migrations? It's *the* feature I've > been dreaming > > of for django. What about "djangostrano.py new-evolution > > evolution_name"? And "djangostrano.py db-evolve"? > > > > 4) For the newbies: Learn python, django, then ruby and > capistrano? > > Manually alter databases when schema evolves? Ugh... Learn > python, > > django, and publish. Draft database modifications using > python, and > > store them to make the database evolve. Sounds better > IMHO :) > > > > 5) I prefer to write my recipes in python instead of adding > another > > language to the mix. I already have to mangle python with > all the > > frontend scripting and markup stuff. I'd love to keep it > simpler. > > > > 6) I don't mind "reinventing the wheel" if it has any > benefits, and > > the > > above are enough for me, though that's only a rough draft of > what I've > > been working on. More to come. > > > > By the way. I don't try to tell anyone that "my tool's > superior to > > tool > > X". I'm just letting the community know. Anyone to join my > efforts? > > Gorgeous. Not? I'd love this kind of tool anyways. I'd be > doing it > > alone, if that's the only way. > > Fair enough, good luck to you. I look forward to seeing the > results ;) > > Cheers, > > Dave > > -- > David Reynolds > [EMAIL PROTECTED] > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
