Using a custom command with defined options will work quite nicely and be much clearer. Thanks for the suggestion!
At the very least, the existing --template option shows an interesting example of using the template engine to render arbitrary files. On Friday, June 8, 2012 4:37:38 AM UTC-5, Jannis Leidel wrote: > > > On 07.06.2012, at 17:32, Luke Plant wrote: > > > On 01/05/12 22:58, Ramiro Morales wrote: > >> On Tue, May 1, 2012 at 11:04 AM, Sam Simmons <s...@samiconductor.com> > wrote: > >>> For app/project templates I found the docs a little misleading when > they say > >>> 'Any option passed to the startapp command' will be added to the > context. > >> > >> You' ve understood the documentation correctly. This is a feature that > is > >> currently (and AFAICT was DOA) not fully implemented because there is > code to > >> process and add the custom command line switches to the context but the > >> validation that the management commands framework performs on the > command line > >> options isn't allowing them to pass. > > > > This sounds like it would be a misfeature. > > > > It is a golden rule of command line apps that typos in options passed to > > the command are not silently ignored. > > > > If I type: > > > > django-admin.py startproject --tempate=/home/me/foo > > > > I should get an exception, not the default template rendered with > > "tempate=/home/me/foo". > > Fully agreed, that's why you'd have to add the options to a command > subclass > in your own code base (with make_option) if you want the command to pass > that > option as a context variable. This was done intentionally to help Django > based apps/frameworks to extend the default startproject with their own > conventions. It was *not* meant to remove the base convention of editing > a setting file to configure a project but rather to supplement it with > basic > metadata. > > > The feature given in the patch on ticket #18277, is however, much more > > like it - you have to pass the context using --add-context > > I can see that some projects need a lot more information when being > created, > but I would prefer to not add a key/value option to the command as it's > obviously > a horrible UX compared to the general functionality of optparse options. > Instead I'd be interested to see more actual use cases for running > startproject > to decide if and how we could move this feature forward. > > Jannis > > -- 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/-/rjk9RQR6aykJ. 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.
