startproject template context

[Sam Simmons]

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)?

e.g.

bp-options.conf:

[options]

coffee

compass

css_dir=sass

js_dir=coffee

~/projects$ django-admin.py --template=/path/to/boilerplate --context=/path/to/bp-options.conf myproject

[Ramiro Morales]

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.

Please open a ticket in our issue tracker.

Thanks.

--
Ramiro Morales

[Sam Simmons]

Ok, thanks. Will open one now.

[Sam Simmons]

Here it is for future reference: https://code.djangoproject.com/ticket/18277

On Tuesday, May 1, 2012 4:58:16 PM UTC-5, Ramiro Morales wrote:

[Luke Plant]

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".

The feature given in the patch on ticket #18277, is however, much more
like it - you have to pass the context using --add-context

Regards,

Luke

--
OSBORN'S LAW
Variables won't, constants aren't.

Luke Plant || http://lukeplant.me.uk/

[Jannis Leidel]

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

[Sam Simmons]

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.