Re: Django deployment à lá Capistrano
I've made a quick and dirty howto about using capistrano with django : http://cyberdelia.tryphon.org/blog/2007/10/27/django-capistrano/ It should help us waiting for a more django and pythonic way to do it ;) Cheers, -- Timothée Peignier http://people.tryphon.org/~tim/ On Mon, 2007-09-10 at 11:26 +0100, David Reynolds wrote: > There are people using capistrano for django [0][1]. Would it not be > better to look at writing a django recipe for capistrano rather than > trying to re-implement it? > > Thanks, > > David --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django deployment à lá Capistrano
I've put up the script I use for deploying our apps, on our internal work server. It's pretty ugly, but It could be extended/improved *alot*. It doesn't check about anything _at all_, it just works or doesn't. :) http://code.google.com/p/djdeliver Anyone who feels like contributing, just let me know, so I can add him. p.s. Use it at your own risk! On Sep 27, 2:36 pm, "Jon Atkinson" <[EMAIL PROTECTED]> wrote: > Is anything happening with this project, or has it died on the vine? > > --Jon > > On 9/13/07, rex <[EMAIL PROTECTED]> wrote: > > > > > Hello. > > > I'd be interested in helping with writing aCapistranoreplacement for > > Django in python (not a port!). > > I'm relatively new to django sites, but quite an old hand at python. > > > Regarding names... surely this is the least important part of a > > project like this :) > > > My 2c though: dojango! That's what it's doing.. it's doing my django > > site... so i don't have to stuff around in an ssh session for 100 > > years to get the thing working :) Flame away. > > > Alex > > > Ps: Chris: estas en españa? verdad? > > > On Sep 10, 3:05 am, qwerty <[EMAIL PROTECTED]> wrote: > > > Well, I'm interesed in the project and as first idea from the bainstrom is > > > the name:Capistrano'surl ishttp://www.capify.org/, why can we call it > > > capipy, the py at the end is a clasic (tm) of projects coded in Python. > > > > Another good idea is to review the concept of the tool to draw what it > > > should and what it should not do: > > > > "automating django's deployment tasks" sounds like a good start for me. > > > > -- > > > Angel > > > > 2007/9/8, Chris Hoeppner <[EMAIL PROTECTED]>: > > > > > Hi there, > > > > > This is just to make it a bit more obvious. I've decided to make up a > > > > python application similar toCapistrano, for Django. > > > > > I plan it to be similar in the sense of "it uses the same goal, and a > > > > few same ideas", and it's not going to be a port ofCapistranoto > > > > Python. > > > > > I've called this project Djangostrano, though I'll come up with a better > > > > name before the folks at 37signals run storms of fury on me :) > > > > > If anyone has done some steps in this direction, please let me know, as > > > > we could join forces. Also, if anyone is *interested* in contributing a > > > > bit, don't hesitate to contact me. > > > > > A few fundamental guidelines lay already, but I'm still in the > > > > brainstorming stage. This is the right stage for anyone to join me. > > > > > I'll be glad to hear from you. > > > > -- > > > > > Saludos, > > > > > Chris Hoeppner, > > > > Passionate about on-line interaction > > > > 627 471 720 > > > > [EMAIL PROTECTED] > > > > www.pixware.org > > > > > -BEGIN PGP SIGNATURE- > > > > Version: GnuPG v1.4.6 (GNU/Linux) > > > > > iD8DBQBG4uAdSyMaQ2t7ZwcRAt1NAKDMwg2Pt4PNNO3E3WcxGCJ7T82QAgCgx+25 > > > > hUzCBlmfaOU4xpcEIO67b2g= > > > > =T5O4 > > > > -END PGP SIGNATURE- --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django deployment à lá Capistrano
On Sep 27, 8:36 am, "Jon Atkinson" <[EMAIL PROTECTED]> wrote: > Is anything happening with this project, or has it died on the vine? > Just a noob here, but why would Django need a Capistrano-like thing? Rails needs it in order to marshal 5 mongrel processes per application, etc etc, for their bloated deployment model. Django is just the familiar apache server mod_python with prefork MPM for any number of django applications. This is one of the main attractions of django, imho. -r --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django deployment à lá Capistrano
Is anything happening with this project, or has it died on the vine? --Jon On 9/13/07, rex <[EMAIL PROTECTED]> wrote: > > Hello. > > I'd be interested in helping with writing a Capistrano replacement for > Django in python (not a port!). > I'm relatively new to django sites, but quite an old hand at python. > > Regarding names... surely this is the least important part of a > project like this :) > > My 2c though: dojango! That's what it's doing.. it's doing my django > site... so i don't have to stuff around in an ssh session for 100 > years to get the thing working :) Flame away. > > Alex > > Ps: Chris: estas en espa�a? verdad? > > On Sep 10, 3:05 am, qwerty <[EMAIL PROTECTED]> wrote: > > Well, I'm interesed in the project and as first idea from the bainstrom is > > the name: Capistrano's url ishttp://www.capify.org/, why can we call it > > capipy, the py at the end is a clasic (tm) of projects coded in Python. > > > > Another good idea is to review the concept of the tool to draw what it > > should and what it should not do: > > > > "automating django's deployment tasks" sounds like a good start for me. > > > > -- > > Angel > > > > 2007/9/8, Chris Hoeppner <[EMAIL PROTECTED]>: > > > > > > > > > Hi there, > > > > > This is just to make it a bit more obvious. I've decided to make up a > > > python application similar to Capistrano, for Django. > > > > > I plan it to be similar in the sense of "it uses the same goal, and a > > > few same ideas", and it's not going to be a port of Capistrano to > > > Python. > > > > > I've called this project Djangostrano, though I'll come up with a better > > > name before the folks at 37signals run storms of fury on me :) > > > > > If anyone has done some steps in this direction, please let me know, as > > > we could join forces. Also, if anyone is *interested* in contributing a > > > bit, don't hesitate to contact me. > > > > > A few fundamental guidelines lay already, but I'm still in the > > > brainstorming stage. This is the right stage for anyone to join me. > > > > > I'll be glad to hear from you. > > > -- > > > > > Saludos, > > > > > Chris Hoeppner, > > > Passionate about on-line interaction > > > 627 471 720 > > > [EMAIL PROTECTED] > > > www.pixware.org > > > > > -BEGIN PGP SIGNATURE- > > > Version: GnuPG v1.4.6 (GNU/Linux) > > > > > iD8DBQBG4uAdSyMaQ2t7ZwcRAt1NAKDMwg2Pt4PNNO3E3WcxGCJ7T82QAgCgx+25 > > > hUzCBlmfaOU4xpcEIO67b2g= > > > =T5O4 > > > -END PGP SIGNATURE- > > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django deployment à lá Capistrano
Hello. I'd be interested in helping with writing a Capistrano replacement for Django in python (not a port!). I'm relatively new to django sites, but quite an old hand at python. Regarding names... surely this is the least important part of a project like this :) My 2c though: dojango! That's what it's doing.. it's doing my django site... so i don't have to stuff around in an ssh session for 100 years to get the thing working :) Flame away. Alex Ps: Chris: estas en españa? verdad? On Sep 10, 3:05 am, qwerty <[EMAIL PROTECTED]> wrote: > Well, I'm interesed in the project and as first idea from the bainstrom is > the name: Capistrano's url ishttp://www.capify.org/, why can we call it > capipy, the py at the end is a clasic (tm) of projects coded in Python. > > Another good idea is to review the concept of the tool to draw what it > should and what it should not do: > > "automating django's deployment tasks" sounds like a good start for me. > > -- > Angel > > 2007/9/8, Chris Hoeppner <[EMAIL PROTECTED]>: > > > > > Hi there, > > > This is just to make it a bit more obvious. I've decided to make up a > > python application similar to Capistrano, for Django. > > > I plan it to be similar in the sense of "it uses the same goal, and a > > few same ideas", and it's not going to be a port of Capistrano to > > Python. > > > I've called this project Djangostrano, though I'll come up with a better > > name before the folks at 37signals run storms of fury on me :) > > > If anyone has done some steps in this direction, please let me know, as > > we could join forces. Also, if anyone is *interested* in contributing a > > bit, don't hesitate to contact me. > > > A few fundamental guidelines lay already, but I'm still in the > > brainstorming stage. This is the right stage for anyone to join me. > > > I'll be glad to hear from you. > > -- > > > Saludos, > > > Chris Hoeppner, > > Passionate about on-line interaction > > 627 471 720 > > [EMAIL PROTECTED] > > www.pixware.org > > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1.4.6 (GNU/Linux) > > > iD8DBQBG4uAdSyMaQ2t7ZwcRAt1NAKDMwg2Pt4PNNO3E3WcxGCJ7T82QAgCgx+25 > > hUzCBlmfaOU4xpcEIO67b2g= > > =T5O4 > > -END PGP SIGNATURE- --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django deployment à lá Capistrano
I really don't see a need for a huge project to accomplish the goals you've outlined: 0) Checking in the local source changes if they have not already been checked in (optional). 1) Logging into the deployment target. 2) Checking out the latest source. 3) Modifying the production database as necessary. 4) Making appropriate changes to settings.py. 5) Running tests 6) Restarting the server 7) Cleaning up and logging out. We have a little shell script that does most of this stuff just fine, in about 10 lines. What makes Capistrano handy is the ability to *transparently* deploy your application across many different machines, and specify roles for each machine which respond to different tasks. I am also *extremely* cautious about having scripts modify a production database with Django. AFAIK, there is currently no standard way of keeping track of schema changes in Django. (This is more feasible in Rails because of migrations). Furthermore, one of the killer features of Capistrano is the ability to completely rollback your entire application to a previous point in time (db schema, data and code base) -- but without a standard schema-evolution tool in Django, how will Djangostrano be able to track & version changes? I would love to see a tool that makes the HARD deployment tasks easy. I suppose what you've outlined is a start, but maybe we'd be better off to work towards a set of individual tools that can be integrated right into django (like schema evolution/versioning, etc) prior to trying to automate these tasks. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django deployment à lá Capistrano
El mar, 11-09-2007 a las 12:26 -0700, Jonas escribió: > Before that someone starts working about this, you must consider this: > > 1. It's already has been created a project with that intention. Its > name is capystrano [1] and althought has been not uploaded code -he > could be working offline-, it would be best contact with its author to > doesn't duplicate work. > > 2. If you think that capistrano -the original tool built with Ruby- is > very complex, has been built a similar tool but more simple. It has > been built too with Ruby in *only 4 days* and its name is Vlad the > Deployer [2] [3]. > > 3. Has been created Webistrano [4], a Web UI for managing Capistrano > deployments, and after to see the screencasts I would ask myself if > the effort is worth the trouble to implement a tool thus when it would > be possible to customize capistrano to deploy Django and then to use > Webistrano. > > > [1] http://code.google.com/p/capystrano/ > [2] http://www.infoq.com/news/2007/08/vlad-the-deployer > [3] http://rubyhitsquad.com/Vlad_the_Deployer.html > [4] http://blog.innerewut.de/webistrano/ I appreciate the time you have taken to gather that information, Jonas. You must know, that I do not intend to "clone" capistrano, thus capystrano (beside knowing nothing about it's owner or how to contact him) is not my path. I do *not* think capistrano is overly complex. I believe it can be improved by our love for python. As for webistrano, I have planned a module that integrates with the admin interface. I think this has been misunderstood. I do not try to make "capistrano for django", as capystrano does. It's tagline says just that. While the approach is similar to capistrano, the path is very different. One of the key pieces will be schema evolution. The other piece will be the task book. Think of a cooking book of recipes for capistrano (or better, don't. It's a very simplistic idea of the application.). As for Vlad, this may be offending, but for "simple", I use a set of bash scripts. You've already seen a bit of them, Jonas. You should know. I know it's possible to use Capistrano with Django. However, I happen to severely dislike Ruby, and thus, I'd like to avoid using it. I use Django for that sole reason. Why stick with Capistrano? Someone has to make the first move. Again, thank you for pointing me to that resources, Jonas. I really appreciate the time you have taken. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django deployment à lá Capistrano
Before that someone starts working about this, you must consider this: 1. It's already has been created a project with that intention. Its name is capystrano [1] and althought has been not uploaded code -he could be working offline-, it would be best contact with its author to doesn't duplicate work. 2. If you think that capistrano -the original tool built with Ruby- is very complex, has been built a similar tool but more simple. It has been built too with Ruby in *only 4 days* and its name is Vlad the Deployer [2] [3]. 3. Has been created Webistrano [4], a Web UI for managing Capistrano deployments, and after to see the screencasts I would ask myself if the effort is worth the trouble to implement a tool thus when it would be possible to customize capistrano to deploy Django and then to use Webistrano. [1] http://code.google.com/p/capystrano/ [2] http://www.infoq.com/news/2007/08/vlad-the-deployer [3] http://rubyhitsquad.com/Vlad_the_Deployer.html [4] http://blog.innerewut.de/webistrano/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django deployment à lá Capistrano
On 9/11/07, Chris Hoeppner <[EMAIL PROTECTED]> wrote: > > I'll be creating a google code page as soon as we settle down on a name. > I like Djangostrano. Sounds nice. But I'm not sure about anyone crying > out something about "ripping other people's ideas". > I don't think I can help with development, but I least I could help with the name. Capistrano is: * A saint: http://en.wikipedia.org/wiki/Giovanni_da_Capistrano * An Italian city: http://en.wikipedia.org/wiki/Capistrano_%28VV%29 * A city in California: http://en.wikipedia.org/wiki/San_Juan_Capistrano%2C_California * A city in Brazil: http://pt.wikipedia.org/wiki/Capistrano Maybe we could play with that and choose a different name, not a variation of Capistrano. I mean like: * Giovanni: First name of the saint * Calabria: Name of the region where Capistrano is located. (I like this.) * Allevato: The name of the mayor. (I don't like this one.) * Ceara: The state where Capistrano is located. Just a few ideas... Cheers! AlvAro "You can't change the world, but you can change your mind." Software Libre: El conocimiento no puede tener dueño. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django deployment à lá Capistrano
Just some names: There is a genre called Jazz Fusion ( http://en.wikipedia.org/wiki/Jazz_fusion) Here's a very long list of names that belong to that category: http://en.wikipedia.org/wiki/List_of_jazz_fusion_artists --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django deployment à lá Capistrano
On Sep 11, 9:20 am, "Alvaro Mouriño" <[EMAIL PROTECTED]> wrote: > Capistrano is: > * A saint:http://en.wikipedia.org/wiki/Giovanni_da_Capistrano > * An Italian city:http://en.wikipedia.org/wiki/Capistrano_%28VV%29 > * A city in > California:http://en.wikipedia.org/wiki/San_Juan_Capistrano%2C_California > * A city in Brazil:http://pt.wikipedia.org/wiki/Capistrano Funny... for some reason I always thought Capistrano was a name of a meat, like pastrami or something. I always thought that was a strange name. :) -Rob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django deployment à lá Capistrano
On Sep 8, 10:47 am, Chris Hoeppner <[EMAIL PROTECTED]> wrote: > This is just to make it a bit more obvious. I've decided to make up a > python application similar to Capistrano, for Django. I'll just echo here that yes, I'd be very interested in this. It's on my queue to learn Capistrano as a deployment tool but so far the manual install and update hasn't been horrible enough to take the time. If there's a Python equivalent all the better! Keep us posted on a URL for the project. I understand you need a name first but a mailing list, django code project, etc would help gather the forces. Personally, I'd avoid a name taken from Capistrano as it might imply it's a simple port which you've said you wanted to avoid. Django itself (and a few other things related) are centered around a jazz theme -- is there anything there that can be related somehow? Cheers! -Rob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django deployment à lá Capistrano
Excellent - I look forward to the URL. --Jon On 9/11/07, Chris Hoeppner <[EMAIL PROTECTED]> wrote: > > I know, I know. Know what? I'll setup a trac site on a domain of mine. > We can always move it somewhere else. > > El mar, 11-09-2007 a las 14:02 +0100, Jon Atkinson escribió: > > I'm not sure the name is really as important as working code. > > > > --Jon > > > > On 9/11/07, Chris Hoeppner <[EMAIL PROTECTED]> wrote: > > > > > > I'll be creating a google code page as soon as we settle down on a name. > > > I like Djangostrano. Sounds nice. But I'm not sure about anyone crying > > > out something about "ripping other people's ideas". > > > > > > El mar, 11-09-2007 a las 11:45 +0100, Jon Atkinson escribió: > > > > Are you going to create a wiki and repository for this project any > > > > time soon? It would be a much more effective means of collaboration > > > > than the mailing list. > > > > > > > > --Jon > > > > > > > > On 9/11/07, Chris Hoeppner <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > 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 > > > > > >
Re: Django deployment à lá Capistrano
I know, I know. Know what? I'll setup a trac site on a domain of mine. We can always move it somewhere else. El mar, 11-09-2007 a las 14:02 +0100, Jon Atkinson escribió: > I'm not sure the name is really as important as working code. > > --Jon > > On 9/11/07, Chris Hoeppner <[EMAIL PROTECTED]> wrote: > > > > I'll be creating a google code page as soon as we settle down on a name. > > I like Djangostrano. Sounds nice. But I'm not sure about anyone crying > > out something about "ripping other people's ideas". > > > > El mar, 11-09-2007 a las 11:45 +0100, Jon Atkinson escribió: > > > Are you going to create a wiki and repository for this project any > > > time soon? It would be a much more effective means of collaboration > > > than the mailing list. > > > > > > --Jon > > > > > > On 9/11/07, Chris Hoeppner <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > 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, > > > > > >
Re: Django deployment à lá Capistrano
I'm not sure the name is really as important as working code. --Jon On 9/11/07, Chris Hoeppner <[EMAIL PROTECTED]> wrote: > > I'll be creating a google code page as soon as we settle down on a name. > I like Djangostrano. Sounds nice. But I'm not sure about anyone crying > out something about "ripping other people's ideas". > > El mar, 11-09-2007 a las 11:45 +0100, Jon Atkinson escribió: > > Are you going to create a wiki and repository for this project any > > time soon? It would be a much more effective means of collaboration > > than the mailing list. > > > > --Jon > > > > On 9/11/07, Chris Hoeppner <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > 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
Re: Django deployment à lá Capistrano
I'll be creating a google code page as soon as we settle down on a name. I like Djangostrano. Sounds nice. But I'm not sure about anyone crying out something about "ripping other people's ideas". El mar, 11-09-2007 a las 11:45 +0100, Jon Atkinson escribió: > Are you going to create a wiki and repository for this project any > time soon? It would be a much more effective means of collaboration > than the mailing list. > > --Jon > > On 9/11/07, Chris Hoeppner <[EMAIL PROTECTED]> wrote: > > > > > > > > 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 -~--~~~~--~~--~--~---
Re: Django deployment à lá Capistrano
Here we are doing just a brainstorm, wiki comes later ;) 2007/9/11, Jon Atkinson <[EMAIL PROTECTED]>: > > Are you going to create a wiki and repository for this project any > time soon? It would be a much more effective means of collaboration > than the mailing list. > > --Jon > > On 9/11/07, Chris Hoeppner <[EMAIL PROTECTED]> wrote: > > > > > > > > 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 -~--~~~~--~~--~--~---
Re: Django deployment à lá Capistrano
> > 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 -~--~~~~--~~--~--~---
Re: Django deployment à lá Capistrano
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" "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 -~--~~~~--~~--~--~---
Re: Django deployment à lá Capistrano
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 -~--~~~~--~~--~--~---
Re: Django deployment à lá Capistrano
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. signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: Django deployment à lá Capistrano
On 10 Sep 2007, at 1:10 pm, Chris Hoeppner wrote: >> Would it not be >> better to look at writing a django recipe for capistrano rather than >> trying to re-implement it? > > Also, we can use a ferrari to drive heavy cargo. It's not really about > "can I use it", but more about "will it be really useful? easy to use? > what degree of easing will i achieve?"... you get it. Why is Capistrano so difficult to use? Of course it will be useful - it's designed to do exactly what you're trying to do. (oh and btw, very poor analogy). > Also, I think the community will benefit from such a tool. Deploying a > django project has always been a complex point in my early days > with it. > Making tasks to automate server setups would also be a great plus > point > for all the django newbies. > > I think merging all of these ideas into one big django-addon would > be a > gorgeous idea for all of us. Not only rails is fun! I agree that the community will benefit from the tool, I just think that perhaps it's silly to reinvent the wheel, but that's just my 2¢ Thanks, 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 -~--~~~~--~~--~--~---
Re: Django deployment à lá Capistrano
> 3) Modifying the production database as necessary. There's one major problem point in making this happen: Rails' migrations. It's pretty simple really, once laid out. Beside svn & tar methods, this is one of the most complex point of this project, and it's also one of the points I'd need most help. > Would it not be > better to look at writing a django recipe for capistrano rather than > trying to re-implement it? Also, we can use a ferrari to drive heavy cargo. It's not really about "can I use it", but more about "will it be really useful? easy to use? what degree of easing will i achieve?"... you get it. Also, I think the community will benefit from such a tool. Deploying a django project has always been a complex point in my early days with it. Making tasks to automate server setups would also be a great plus point for all the django newbies. I think merging all of these ideas into one big django-addon would be a gorgeous idea for all of us. Not only rails is fun! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django deployment à lá Capistrano
> "automating django's deployment tasks" sounds like a good start for me. A rough list of what I consider those tasks to be: 0) Checking in the local source changes if they have not already been checked in (optional). 1) Logging into the deployment target. 2) Checking out the latest source. 3) Modifying the production database as necessary. 4) Making appropriate changes to settings.py. 5) Running tests 6) Restarting the server 7) Cleaning up and logging out. I'm sure there is more to this (particularly, point three is vastly over-simplified :-P), but please add to this as necessary. --Jon > > -- > Angel > > 2007/9/8, Chris Hoeppner <[EMAIL PROTECTED]>: > > > > Hi there, > > > > This is just to make it a bit more obvious. I've decided to make up a > > python application similar to Capistrano, for Django. > > > > I plan it to be similar in the sense of "it uses the same goal, and a > > few same ideas", and it's not going to be a port of Capistrano to > > Python. > > > > I've called this project Djangostrano, though I'll come up with a better > > name before the folks at 37signals run storms of fury on me :) > > > > If anyone has done some steps in this direction, please let me know, as > > we could join forces. Also, if anyone is *interested* in contributing a > > bit, don't hesitate to contact me. > > > > A few fundamental guidelines lay already, but I'm still in the > > brainstorming stage. This is the right stage for anyone to join me. > > > > I'll be glad to hear from you. > > -- > > > > Saludos, > > > > Chris Hoeppner, > > Passionate about on-line interaction > > 627 471 720 > > [EMAIL PROTECTED] > > www.pixware.org > > > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1.4.6 (GNU/Linux) > > > > > iD8DBQBG4uAdSyMaQ2t7ZwcRAt1NAKDMwg2Pt4PNNO3E3WcxGCJ7T82QAgCgx+25 > > hUzCBlmfaOU4xpcEIO67b2g= > > =T5O4 > > -END PGP SIGNATURE- > > > > > > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django deployment à lá Capistrano
Well, I'm interesed in the project and as first idea from the bainstrom is the name: Capistrano's url is http://www.capify.org/, why can we call it capipy, the py at the end is a clasic (tm) of projects coded in Python. Another good idea is to review the concept of the tool to draw what it should and what it should not do: "automating django's deployment tasks" sounds like a good start for me. -- Angel 2007/9/8, Chris Hoeppner <[EMAIL PROTECTED]>: > > Hi there, > > This is just to make it a bit more obvious. I've decided to make up a > python application similar to Capistrano, for Django. > > I plan it to be similar in the sense of "it uses the same goal, and a > few same ideas", and it's not going to be a port of Capistrano to > Python. > > I've called this project Djangostrano, though I'll come up with a better > name before the folks at 37signals run storms of fury on me :) > > If anyone has done some steps in this direction, please let me know, as > we could join forces. Also, if anyone is *interested* in contributing a > bit, don't hesitate to contact me. > > A few fundamental guidelines lay already, but I'm still in the > brainstorming stage. This is the right stage for anyone to join me. > > I'll be glad to hear from you. > -- > > Saludos, > > Chris Hoeppner, > Passionate about on-line interaction > 627 471 720 > [EMAIL PROTECTED] > www.pixware.org > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQBG4uAdSyMaQ2t7ZwcRAt1NAKDMwg2Pt4PNNO3E3WcxGCJ7T82QAgCgx+25 > hUzCBlmfaOU4xpcEIO67b2g= > =T5O4 > -END PGP SIGNATURE- > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
