#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 , 14 years ago
| Attachment: | ticket18277.diff added |
|---|
comment:1 by , 14 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 , 14 years ago
| Triage Stage: | Unreviewed → Design decision needed |
|---|
follow-up: 5 comment:4 by , 14 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 , 14 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 , 13 years ago
| Triage Stage: | Design decision needed → Someday/Maybe |
|---|
Discussion here : https://groups.google.com/forum/#!topic/django-developers/0aJMMZ7UjHk
jezdez suggested : make your startproject command by leveraging "make_option"
comment:7 by , 13 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 , 13 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 , 13 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 , 13 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
Code and documentation patch