On Tue, Jul 13, 2010 at 2:23 PM, maxweld <da...@maxwell.uk.net> wrote: > I would like to propose that all commands in core.management be > modified to enable command output to be directed to self.stdout and > self.stderr so that the command output can be captured and made > accessible to an application. > > I use a virtual web hosting environment where no shell access is > permitted. I would like to set up an administrative web interface > which enables commands to be executed and the command output > redisplayed to the user. However, as commands currently send output > directly to stdout or stderr, the comand output is not readily > accessible (Django 1.2.1). > > Discussions with Russ McGee on Django Users suggested that some
Magee. I'm not Scottish :-) > commands, for testing system purposes, are now sending to self.stdout > and self.stderr, allowing the target to be redefined and the output to > be captured. Only dumpdata and loaddata commands have currently been > converted in trunk. I am proposing extending this to all commands in > core.management, and suggest that this should be promoted as the norm > for custom developed commands also. > > If agreed, the work required to implement would be: > a) convert existing commands > b) document the feature > c) improve documentation of the existing feature allowing applications > to construct their own commands > d) improve documentation of how to execute commands programatically > (as opposed to in a shell) Seconded, and carried. I've already said I'll accept any patch that implements any (or preferably all) of these points. > If there is agreement, I am happy to undertake the above although > would appreciate a mentor being available for advice from time to time > as this would be my first contribution. I'm happy to give you any feedback you need; if you post to django-dev when you need assistance or feedback, I'll try to respond; if I don't, someone else hopefully will. > Longer term, if an administrative web interface to commands is to be > provided, we would need to devise an interface that adapted well into > the existing administrative interface. However, I see this as a second > stage in the process. First we need the command output to be > available. There may well be a place for these commands to be exposed via a web interface (especially if you're building a shared hosting type environment), but I'm not convinced that this is something that is appropriate to be baked into Django's core. Firstly, it's a bit of an edge case; the biggest use case for this sort of facility is to support a virtual server for which you don't have shell access. I don't have any firm numbers, but I suspect that this is an edge case of Django deployments. Secondly, some management commands aren't really well suited to execute on the same server that is serving them. It may be fine to have one server executing management commands on another, though (especially if you're setting up some sort of push-button hosting environment). Thirdly, some management commands can be time consuming or have the potential for introducing database locks; as such, they aren't well suited to execution in the request/response cycle. This means you should be looking at implementing this using a job queue, and Django is agnostic when it comes to such issues. That said, if such an administrative interface were to be introduced, it would almost certainly be as a contrib application. The usual path for adding new contrib applications is for them to start as a standalone project, and then be integrated when an argument can be made that they are a "defacto standard implementation of a common pattern". If this is something you're enthused about, I heartily encourage you to start it as a standalone project. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
