#18277 closed Bug (fixed)
Startproject/app template documentation confusing
Reported by: | Owned by: | domguard | |
---|---|---|---|
Component: | Documentation | Version: | 1.4 |
Severity: | Normal | Keywords: | startproject startapp template |
Cc: | dguardiola@… | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
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 lead me to believe 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.cfg:
[options]
css_dir=sass
js_dir=coffee
~/projects$ django-admin.py --template=/path/to/boilerplate --context=/path/to/bp-options.cfg myproject
I would definitely be willing to give this a shot if it is deemed useful.
Thanks!
Attachments (1)
Change History (14)
by , 12 years ago
Attachment: | ticket18277.diff added |
---|
comment:1 by , 12 years ago
Cc: | added |
---|---|
Component: | Documentation → Core (Management commands) |
Has patch: | set |
Owner: | changed from | to
Status: | new → assigned |
Indeed, the doc promise things that aren't happening in the code...
I've exchanged by email with sam, and another common proposal is just to have a command parameter that would accept additional template variables.
That's what the attached patch does, with a --add_context parameter
The proposed syntax (documented in the help of the command) is :
django-admin.py startproject --template=templ/folder/ --add_context=foo:bar,key:value mynewproject # or abbreviated form django-admin.py startproject --template=templ/folder/ -a foo:bar,key:value mynewproject
The string is parsed and key:values added to the template dict.
Also added the documention modification
comment:3 by , 12 years ago
Triage Stage: | Unreviewed → Design decision needed |
---|
follow-up: 5 comment:4 by , 12 years ago
Having written the feature in question, I'm not convinced this is a good idea. Needs more discussion on the mailing list.
comment:5 by , 12 years ago
Replying to jezdez:
Having written the feature in question, I'm not convinced this is a good idea. Needs more discussion on the mailing list.
I hope you will at least keep the template option and continue to replace {{ project_name }}. This has already been useful for a django html5 boilerplate clone.
comment:6 by , 12 years ago
Triage Stage: | Design decision needed → Someday/Maybe |
---|
Discussion here : https://groups.google.com/forum/#!topic/django-developers/0aJMMZ7UjHk[[BR]]
jezdez suggested : make your startproject command by leveraging "make_option"
comment:7 by , 12 years ago
Triage Stage: | Someday/Maybe → Design decision needed |
---|---|
Type: | New feature → Bug |
So this could be turned to a documentation bug to correct as the advertised feature does not exists !!
comment:8 by , 12 years ago
If a design decision can't be made, the documentation bug should be fixed to prevent other users from assuming that the documentation is correct.
I've just been trying to use this non-existent functionality in a new 1.5 project.
comment:9 by , 12 years ago
Component: | Core (Management commands) → Documentation |
---|---|
Triage Stage: | Design decision needed → Accepted |
Accepting as a documentation fix, the current wording trips up a lot of people (as seen on IRC and here).
comment:11 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Code and documentation patch