Django has high start costs, weight

[aaronsw]

My biggest issue with Django right now is that it's so hard and heavy to get started. Here are all the administrative (non-code writing) things you have to do:

1. Install Django.
2. Run startproject, which creates six things.
3. Create a database.
4. Update several variables to use the database.
5. Update your PYTHONPATH variable.
6. Update your DJANGO_SETTINGS_MODULE variable.
7. Run init.
8. Run startapp, creating six more things.
9. Update INSTALLED_APPS.
10. Run install.

10 steps, 12 files. For comparison, here are the only two necessary steps:

1. Install Django.
2. Give Django the URL to an existing database (ala SQLObject) and a prefix so it doesn't reuse any tables.

Imagine how much simpler that tutorial document would be. Imagine how many more people would just start using Django, instead of putting it off or giving up. Imagine how people would start using bits and pieces of Django everywhere, instead of just their website.

I'll follow by posting tickets with more concrete suggestions, but I'd like to propose this sort of simplicity as a new design principle. You shouldn't have to fit your code into Django, Django should fit into your code.

[hugo]

Uhm - the startproject and startapp and stuff are only needed when you build _new_ projects - and in those cases you will have to write the actual code. There is no way around that when writing something new - it can't just magically spring into existance. Complaining about startproject and startapp to provide a basic layout is rather weird, especially since they are only there as helpers - you are not required to use them, but it "tells you how to do things" (which is a good thing to do for a framework!).

The other steps aren't really new steps - replacing the requirement to create a dabase with "point to an existing database" is rather silly, as that existing database needs to come into existance anyway - it's not a step in "getting Django running" that you need to create a database at all - it's a requirement of "using any database" that you need to create it first.

Getting Django to start (for a _new_ project):

• django-admin startproject (creates the structure)
• edit settings file
• django-admin startapp for each app (creates the structure)
• write code
• django-admin.py init
• django-admin.py createsuperuser
• django-admin.py install for every app

That's actually not bad for a framework with a strong notion of difference on "project" and "app" - one of the big niceties of Django, as you can easily port and reuse applications between different projects. Mind, this is a tutorial for _beginners_ - you give them basic tools and tell them what they do and give them guidance.

Advanced hackers way to start a django project:

• create project structure and settings file
• django-admin.py init
• django-admin.py createsuperuser
• write code
• django-admin.py install

Can't see how that really is a big burdon. Yes, I often create my project and app structures by hand.

[aaronsw]

As a practical matter, I think the tutorial shouldn't use startproject and startapp then. It definitely frustrates and confuses people who are just starting with Django in my experience (n=2).

I should be able to create one file with the URL conf and views and another file with the database model and just have that work. Then the tutorial should show people how to grow this into an app inside a project when/if that becomes necessary. But the more nonsense like this you put up front, the more you drive people away.

[aaronsw]

OK, here's some sample code that should work under the lightweight Django:

import web, db

urls = (
    (r'^foo/$', 'index'),
)

def index(request):
    return HttpResponse("This is a test.")

if __name__ == '__main__': web.run()

The web module is a simplified interface to all the common Django stuff. db is where the models for the app are stored. web.run detects whether it's being called as CGI, FCGI, or command line and does the right thing (i.e. runserver for the command line) and gets the urls from its calling module.

I'm currently working on web.py -- it looks like it'll require some changes to be able to avoid the DJANGO_SETTINGS_MODULE and ROOT_URLS stuff.

[rjwittams]

aaronsw,
I think most of your issues would be far better discussed on the mailing lists at this stage. You make several emotive appeals ("driving away", "giving up"), etc etc - these really aren't going to sway anyone as to the technical merits. So please bring these issues up on the mailing list, rather than doing a bunch of work and then being surprised that no one agrees with your premises.

[Adrian Holovaty]

Yeah, I agree with rjwittams -- it'd be great if you brought it up on the mailing list.

[Adrian Holovaty]

Closing this ticket because it's broad rather than having a specific bug.