Provide a boiler plate free ./manage.py startapp command

[anonymous]

Django still requires a lot of boiler plate to start with.

Running manage.py startapp could ask questions just like manage.py syncdb does to create super user, such as :

• do you want to create a hello_world view and template ? (this will create a views.hello, app/templates/app/base.html and app/templates/app/hello.html files and an entry in app/urls.py if it exists)
• do you want to add the app to INSTALLED_APPS ? (this will copy it the first INSTALLED_APPS it founds and appears only if you don't have more than a simple settings.py file)
• do you want to add the app to the project urlconf ? (this will appears only if you have nothing more than a simple project/urls.py file)

Then it prints what it did with full path to edited files, so people can actually SEE how you bootstrap an app.

If you choose no to any of theses question, the command gives you helpful clues such as :

"You may want to add this app to your INSTALLED_APPS and project.urls.py"

Of course you can disable all that stuff with --noinput.

[Russell Keith-Magee]

I'm not sure I see the value here.

Firstly, there's a problem with failure modes. It's easy to say "just add X to INSTALLED_APPS, and Y to urls.py", but even in your explanation you've referred to "simple" urls.py files. What's a "simple" file? How do you identify it reliably? And how will the app behave when it doesn't find a "simple" file? The worst outcome here would be a command that "automagically" completely breaks your settings/urls file, and this sort of breakage would be easy to do accidentally when rewriting files. So, you would have to be ultraconservative, which means you'll fall back to just printing the instructions most of the time.

Secondly, there's the argument that we shouldn't be hiding details with magic commands. I'd almost argue that startapp should be deprecated. Speaking personally, I can't remember the last time that I used it. We shouldn't be masking the internals of django apps by making them seem mystical. An app is just a Python module that contains a models.py file (although even that restriction could be lifted). If you want an urls.py file, you can write one -- but it doesn't even need to be called urls.py. You want views? Put them in a file as well -- ideally, one called views.py. Bootstrapping commands hide this base philosophy, and sophisticated bootstrapping commands make it even harder to spot. I'd rather remove the crutch, rather than make the crutch more powerful.

Marking wontfix; if you want to argue your case, please start a discussion on django-dev.

[Aymeric Augustin]

I had the same reaction as Russell yesterday, except I was too lazy to write down the explanation.

[anonymous]

Then what about making a project template with these included and commented, so newcomers can get a very quick dive into django ? Right now, writing you first django view + template + rooting without somebody to teach you take much more time it should. Documentation is good, but nothing beats working code.

We could them make startproject offer to create a bootstrap project instead if the user whishes so.

[Aymeric Augustin]

I recently took the opposite path. I simplified the opposite path because it's annoying to remove auto generated stuff whenever one creates a new application.

[Russell Keith-Magee]

I agree. Django wears a lot of criticism (incorrectly, IMHO) for being a bloated monolithic framework. Part of that comes from the fact that a "simple" app appears to be really big, when in reality, it doesn't need to be any more than one or two files. Having a huge project template with lots of mostly empty files reinforces that false belief.

There's also tutorial value in having people type all the code. That way, they're forced to understand what they're putting in place, and they don't get the perception that there's lots of magic floating around in these extra files.

On top of all that - there isn't *that* much boilerplate to start with, and if you *really* need the help with the typing, most decent text editors have snippet packages for Django that will autocomplete a stub model definition, URLpattern definition, etc.

[anonymous]

I have been training people for django for 3 years now. And I assure you, from the beginer point of view, this is both scary and confusing.

It doesn't need to be the default template, just provide the option to do so, in the default setpu.

And comment the resulting output, a LOT.

You are all experienced programmers, but if you want new blood to come to django, you need to think about the PHP newbie trying to have a quick grasp of django.

PHP really took of when EasyPHP arrived on the market, effectivly hidding the boiler plate of setuping a PHP env. Now setuping a django env is easier, thanks to the dev serveur and sqlite. But still, there is a lot of room for improvement.

Really, make the test. Take a kid out of IT class, or a sysadmin, or even a rail dev, and mesure the time he can actually make a hello world by himself, with a template. It's way longer than you think.

[anonymous]

Personnaly, it takes me 5 minutes to setup a django project without using a project template, and I know the damn thing by heart.

You startproject, you create your app, you add the app to INSTALLED_APP, you create a view, you hook it to the app urls.py file, then hook the app urls.py file into the project urls.py file, you create a templates dir, with a subdir, with a base.html that you extend with your view template.

Then you runserver.

If you want css, you have to create your static dir, then import the static tag, then add the entry in html.

And if you want the admin, don't forget to syncdb.

I know that stuff because I did it a 1000 times.

Somebody who is starting ? I will take him hours. Litteraly.

[Aymeric Augustin]

Django's core team includes people whose full time job includes teaching Djang to beginners. Obviously we chose a different pedagogic approach to the one you favor. But that doesn't mean we aren't aware of the challenge. In fact, we've given lots of attention to this topic.

Django's answer is:

• A comprehensive tutorial for beginners, forcing them to think about what they're doing and understand how the pieces fit together. This isn't common practice in some programming communities, but it's part of the values of the Django community (and of being a good programmer in general IMO).
• Complete documentation, that takes time to read and digest, but smoothes the learning curve — you're not going to hit a wall when you reach the limits of autogenerated stuff.
• Support for custom project templates for advanced users who have done it 10 times and know what they need. I'm surprised to hear that you have done it 1000 times and are still doing it manually. Check the documentation!

[anonymous]

I don't do it manually anymore, I do it manually in lectures of course. I was not expecting this kind of sarcastic tone here.

I'm sorry I bothered you. I won't do it again.

[Aymeric Augustin]

Sorry, I didn't mean to be sarcastic, I was merely pointing out the exaggeration in your previous message. (FWIW I'm not a native speaker.)

Anyway, I hope this helps you understand why your proposal doesn't fit well in Django's philosophy. If you'd like to discuss this further, I suggest writing to the DevelopersMailingList, in order to reach to a wider audience.