|startproject template context||Sam Simmons||5/1/12 7:04 AM|
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. This got me thinking I could add arbitrary options to the command and pass them in to the context, which would make for some highly configurable app/project boilerplates. But, from looking at the source I gather by 'any options' they meant any valid options for the startapp/project commands.
Do you think it would be a cool feature to be able to pass any options or a file that defines additional context (maybe something consumable by ConfigParser)?
~/projects$ django-admin.py --template=/path/to/boilerplate --context=/path/to/bp-options.conf myproject
|Re: startproject template context||Ramiro Morales||5/1/12 2:58 PM|
On Tue, May 1, 2012 at 11:04 AM, Sam Simmons <s...@samiconductor.com> wrote: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.
Please open a ticket in our issue tracker.
|Re: startproject template context||Sam Simmons||5/6/12 4:57 AM|
Ok, thanks. Will open one now.
|Re: startproject template context||Sam Simmons||5/6/12 5:27 AM|
Here it is for future reference: https://code.djangoproject.com/ticket/18277
|Re: startproject template context||Luke Plant||6/7/12 8:32 AM|
On 01/05/12 22:58, Ramiro Morales wrote: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
The feature given in the patch on ticket #18277, is however, much more
like it - you have to pass the context using --add-context
Variables won't, constants aren't.
Luke Plant || http://lukeplant.me.uk/
|Re: startproject template context||Jannis Leidel||6/8/12 2:37 AM|
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
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.
|Re: startproject template context||Sam Simmons||6/10/12 9:33 PM|
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.