allow startproject, startapp to write into existing directory or a specified directory

[Preston Holmes]

There might be various times you would want to "convert" an existing directory into a django project/app

such might be the case for when you want to put a project under normal SVN flow of svnadmin create

but there could be a number of circumstances - especially once #15372 is fixed where you want to turn an existing dir into a project container.

[Preston Holmes]

This relies someone on the files "manage.py" and "models.py" being "special markers" - but they are as good as any. manage.py may one day go away, in which case settings could be checked.

​https://github.com/django/django/pull/65

[Preston Holmes]

I've expanded the scope of this ticket to not only cover the case of an existing directory of the specified name, but to allow a second argument to specify a different existing directory, or the current working directory

[Aymeric Augustin]

See ​http://groups.google.com/group/django-developers/browse_thread/thread/44b70a37ff73298b where this idea was debated.

[Carl Meyer]

I don't think there's any reason not to do this, at least based on the discussion in that thread. It's clear that a number of people want the ability to run startproject in an already-existing directory and have it populate that directory rather than create a new one; this would give them that.

[Jannis Leidel]

I've worked on this: ​https://github.com/jezdez/django/compare/feature/project-app-templates

• Added ability to pass the project or app directory path as the second argument
• Added --template option for specifying custom Python packages containing project and app templates
• Cleaned up tests a little while I was there

[Jannis Leidel]

Oh, also, this switches the rendering of the project/app templates to using Django's template engine, as it seemed sensible with regard to extended templates.

By default it uses the optparse option dict as the context for the templates (next to name, directory of new project/app), so it should be easily enough to implement custom startproject/startapp commands for whatever use case by simply adding optparse options.

[Julien Phalip]

This is a really awesome feature and I can see a lot of power users wanting to use startapp/startproject now, not just newbies.

I only had a couple of minor remarks:

• The 'versionadded' directive is missing for --template.

• Could/should the doc be extended instead of "see the source_ for more details"? :-)

• It'd be good to clarify in the doc that --template is particularly useful for providing a *custom* layout for your project and app. This is currently only explicitly said in the release notes.

• Also, maybe it's just me but when I first looked at the patch I was a little confused about what --template was for. I'm more used to hearing about a project's or app's *layout*. Maybe it would be clearer if the option was called --layout instead? This is not a big deal though.

[Julien Phalip]

On a second thought, since django.conf is already using the 'app_template' and 'project_template' terminology, then its' probably to just keep the same (ie --template as you've done).

[Jannis Leidel]

In [17246]:

Fixed #17042 -- Extended startproject and startapp management commands to better handle custom app and project templates. Many thanks to Preston Holmes for his initial patch and Alex Gaynor, Carl Meyer, Donald Stufft, Jacob Kaplan-Moss and Julien Phalip for code reviewing.

• Added ability to pass the project or app directory path as the second argument
• Added --template option for specifying custom project and app templates
• Cleaned up admin_scripts tests a little while I was there

[Carl Meyer]

In [17340]:

Fixed #17503 -- A destination directory passed to startproject or startapp as optional second argument is now reused as the project/app directory, rather than a new project/app directory created within it. Refs #17042.