Thanks for your feedback, Cal, You're right about the documentation, some very useful parts aren't even documented at all. (There are comments in the code, but there are some little things you wouldn't know from the readme.)
During the last years I also put most of the effort in experimenting and getting something really useful. It took a while before I got there, and it didn't make sense to document features which were to be refactored every now and then. However, now I feel its quite stable. I should start making better documentation, and a lot of usage examples. I also cannot deny that the learning curve may be a little bit steeper then Fabric in the very beginning, but soon you will see the advantages. If only I were as good in selling a project as I can code. :) Anyway, I hope this can also improve automatic deployment of Django applications for other people. Cheers, Jonathan Le lundi 10 décembre 2012 00:15:58 UTC+1, Cal Leeming [Simplicity Media Ltd] a écrit : > > 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 > <jonathan...@gmail.com<javascript:> > > 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 >> django-d...@googlegroups.com<javascript:> >> . >> To unsubscribe from this group, send email to >> django-develop...@googlegroups.com <javascript:>. >> 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 view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/5fPxtSy12ysJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
