Hi Jonathan, Just from a very brief point of view.. my eyes started to glaze over whilst looking at the github README, and even more so when I looked at the code.
Even if this was the best thing since sliced bread, the documentation in its current state leaves me with the feeling of "why do I want to use this". I think what would benefit this project massively is good/easy to read documentation, with a simple overview section explaining common uses, what makes it better than alternatives, etc.. maybe via readthedocs..? Statements such as "It's as declarative as possible.." sound impressive, but don't really give me much insight into what this is, and why I'd want to use it. Hope this helps! Cal On Sun, Dec 9, 2012 at 3:30 PM, Jonathan Slenders < [email protected]> wrote: > Hi Everyone, > > In the past there have been some discussionh about how to deploy Django > web applications through SSH. How to use Fabric or other tools, and whether > we should provide or maybe force users to deploy applications according to > a certain conventions. > > Back then, maybe already more than a year ago, I said that I was working > on my own deployment tool. [1] Something that could be used instead of > Fabric. It's a tool which could probably help a lot of you, although it can > take a while to adopt. The core consists of high quality code. I took me a > while before I felt confident enough for releasing this, and it has been > refactored more then any project I did before. Things still can be > improved, but it's ready to share with you. > > Key features are: > > - Interactive execution of remote commands. Locally, they will appear > in a pseudo terminal (created with openpty), so that even editors like Vim > or Emacs works fine when you run them on the remote end. You can easy start > an interactive shell on any host as well. > - Reusability of all deployment code is a key point. It's as > declarative as possible, but without loosing Python's power to express > everything as dynamic as you'd like to. Deployment code is hierarchically > structured, with inheritance where possible. > - Parallel execution is easy when enabled, while keeping interaction > with these remote processes possible through pseudoterminals. Every > parallel task gets his own terminal, either a new xterm or gnome-terminal > window, a tmux pane, or whatever you'd like to. > - Logging of your deployments. New loggers are easily pluggable into > the system. > > > So, enjoy! > > So, what does it have to do with Django? I have a setup-definition of what > we use for Django deployment [2]. However, I suppose that quite a lot of > people aren't using uwsgi like us. So, I'd like to know what the most > common use cases of Django deployment are. If I can cover most cases, it's > very easy for end-users to pick one, override what they don't like, and > enjoy the full power of this deployment system. > > For instance, to demonstrate the power. If we want to connect to a Django > shell_plus of our Mobile Vikings production system, we type in the > interactive shell: > > > mobile_vikings django shell_plus > > This will call the shell_plus function of our django setup, it will ask on > which host the shell needs to be started, and immediately fire an > interactive shell_plus of the remote server in your terminal. > > [1] https://github.com/jonathanslenders/python-deployer > [2] > https://github.com/citylive/citylive-operations/blob/master/deployment/deployer/contrib/services/django.py > > I'll publish one of these days on pypi. > > All feedback is welcome. For bugs/feature requests on things which arn't > Django related, please go to the github. > > Cheers, > Jonathan > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-developers/-/k4RS_9Kmn9cJ. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
