Code

Opened 9 years ago

Closed 9 years ago

Last modified 8 years ago

#853 closed defect (worksforme)

Django has high start costs, weight

Reported by: aaronsw Owned by: adrian
Component: Metasystem Version:
Severity: normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

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.

Attachments (0)

Change History (6)

comment:1 Changed 9 years ago by 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.

comment:2 Changed 9 years ago by 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.

comment:3 Changed 9 years ago by 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.

comment:4 Changed 9 years ago by 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.

comment:5 Changed 9 years ago by adrian

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

comment:6 Changed 9 years ago by adrian

  • Resolution set to worksforme
  • Status changed from new to closed

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

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.