manage.py startapp suggestions
Tom Smith
James Bennett
> This is my very crude attempt, which first calls startapp, then does
> standard stuff that ALWAYS seem to have to do and ALWAYS forget like:
> Add a urls.py for my app...
> Add a URL pattern to load static images
> Create the folder to host the static images
> Put some examples in the views calls and add standard imports
> Create all the classes in models.py that I think I'm gonna need (but not
> call syncdb yet)
> Add __str__ calls to all classes, and Admin classes (it's easier to delete
> them than to add them by hand later)
> Docstrings, one day I may comment my code.
Hmm... if we do it, this feels like something that should be kept
separate from the standard manage.py; I can certainly see it being an
immense help to developers who are just starting to work with Django,
but I can also see more experienced users saying "I just want a blank
app, without having to answer all these questions at the prompt".
So maybe this could work more as an introductory tool, so that once a
developers are familiar enough with Django to make the choice, they
can decide to keep using it or switch to the standard manage.py app
skeleton.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
Myt...@gmail.com
> separate from the standard manage.py; I can certainly see it being an
> immense help to developers who are just starting to work with Django,
> but I can also see more experienced users saying "I just want a blank
> app, without having to answer all these questions at the prompt".
>
> So maybe this could work more as an introductory tool, so that once a
> developers are familiar enough with Django to make the choice, they
> can decide to keep using it or switch to the standard manage.py app
> skeleton.
>
> --
> "Bureaucrat Conrad, you are technically correct -- the best kind of correct."
Why not something like a "python manage.py startapp verbose"?
Malcolm Tredinnick
I'm with James on this one: I think it's probably a fairly useful tool
to have, but it's not something that's necessarily appropriate for the
core manage.py program. The debate isn't about what words to use to
invoke it -- it's about whether having that functionality in the code is
a good idea.
The reasoning is that whilst it's not impossible to add this type of
functionality, now we suddenly have a few dozen or a hundred more lines
of code that need to be maintained for something that isn't really core
functionality.
It would be very easy to write a "getting started wizard" that leverages
a lot of the stuff already inside manage.py. Have a look at the code
there. You can see it splits up most of the functionality into separate
functions (there's a command line arg to function mapping towards the
bottom of the file that does just that). So a third-party application
that wants to create some directories, fill in a bunch of stuff and
provide the whole "getting started" framework skeleton doesn't have to
replicate any of the existing work. Import django.core.management and
call out to that. The extra stuff can then be kept separate and both
sides remain maintainable.
Regards,
Malcolm
Tom Smith
On Wed, 2007-03-21 at 23:36 -0700, Myt...@gmail.com wrote:Hmm... if we do it, this feels like something that should be keptseparate from the standard manage.py;
The reasoning is that whilst it's not impossible to add this type offunctionality, now we suddenly have a few dozen or a hundred more linesof code that need to be maintained for something that isn't really corefunctionality.
Malcolm Tredinnick
>
> On 22 Mar 2007, at 06:57, Malcolm Tredinnick wrote:
>
> >
> >
> > On Wed, 2007-03-21 at 23:36 -0700, Myt...@gmail.com wrote:
> > > > Hmm... if we do it, this feels like something that should be
> > > > kept
> > > > separate from the standard manage.py;
> > > >
>
>
> I don't mind "where" this functionality "lives"... and really don't
> want it to become complicated because then people who don't understand
> the guts of Django won't be able to use it...
>
>
> Even putting examples in the comments would help me...
>
> > The reasoning is that whilst it's not impossible to add this type of
> > functionality, now we suddenly have a few dozen or a hundred more
> > lines
> > of code that need to be maintained for something that isn't really
> > core
> > functionality.
>
>
> You can't argue, can you, that something shouldn't be included because
> it requires a few lines of code?
Certainly I can argue this way and I am. Every line of code that is
added to core needs to be maintained ad infinitum and so should be
considered carefully. I run through the same argument -- usually just in
my head -- every time additions are proposed. In this case, my feeling
is that adding this extra functionality to management.py -- the core
management routines in Django -- is not the right place.
> As for defining what "core" functionality is... for me, usability is
> a core functionality... being teachable is core... and for a few lines
> of code, being helpful/intelligent is at very least good marketing :-)
> It makes for a great demo...
Again, I'm not arguing against the tool itself, although not having it
does not mean we don't have usability, teachability or marketing
possibilities; let's keep things in perspective. It's a good idea. But I
don't think it should be part of management.py.
What you have proposed is definitely going to be useful in some cases,
for exactly the reasons you mention. It would be a great tool to have
for people starting out. It becomes less useful as you get more
experienced, because there is no "one size fits all" approach to
application layout. This sets it aside from the other code in
management.py, which is always stuff you need to use.
Another argument for making this a separate application is that, from a
usability perspective, when somebody is in the situation where they need
an aid like this, is it better to say "run this program and give it the
right argument from amongst 15 different choices (so the help screen is
pretty imposing)" or "run this other program over here, no args
required"? The latter is less error-prone, the former would be the case
if this was added as an option accessible django-admin.py.
If somebody were to write this app, I think we should consider including
it in django/extras/.
Regards,
Malcolm
Tom Smith
It becomes less useful as you get more
experienced, because there is no "one size fits all" approach to
application layout.
If somebody were to write this app, I think we should consider including
it in django/extras/.
James Bennett
> my head -- every time additions are proposed. In this case, my feeling
> is that adding this extra functionality to management.py -- the core
> management routines in Django -- is not the right place.
I agree it doesn't belong in management.py, but I do think that if it
can be polished up a bit it'd be a worthy addition *somewhere* in
Django. I'm just not sure where yet... contrib is an obvious place
(contrib.gettingstarted?), but it'd probably be too easy to miss
there.
doug.na...@gmail.com
should it really do' stage.
Unfortunatly given your example, 90% of what you want (urls.py with
static file handling, a media directory, building the actual model)
are things I expressly do NOT want the wizard to do for ME. (I have my
own genapp.py tool I use for creating new apps.)
I do believe this is needed in django, and maybe it should come as
part of the core, or be in the contrib, or maybe not.
The first step is to write it and host it as a third party application
and give it support.
This is a volunteer open source project after all, and while people
are interested in this feature, if no one steps up to implement it AND
support it going forward, it will not happen.
All it takes is one person to do this, and then propose its added to
the core, and it will be. This happened with ElementTree in core
python, with generic relations, and newforms in Django,
I guess I am saying, GREAT IDEA! We can figure out where/if it belongs
in django core later. Where's the code? ^_^;;;
-Doug
On Mar 22, 12:16 pm, "James Bennett" <ubernost...@gmail.com> wrote:
Tom Smith
Unfortunatly given your example, 90% of what you want (urls.py with
static file handling, a media directory, building the actual model)
are things I expressly do NOT want the wizard to do for ME. (I have my
own genapp.py tool I use for creating new apps.)
I guess I am saying, GREAT IDEA! We can figure out where/if it belongs
in django core later. Where's the code? ^_^;;;
doug.na...@gmail.com
Thanks for going forward with this, there are alot of people who
want something like this.
On Mar 23, 8:17 am, Tom Smith <t...@everythingability.com> wrote:
> > Unfortunatly given your example, 90% of what you want (urls.py with
> > static file handling, a media directory, building the actual model)
> > are things I expressly do NOT want the wizard to do for ME. (I have my
> > own genapp.py tool I use for creating new apps.)
>
> Interesting... I'd like to know why you don't want those things and
> see your own genapp script...
It will be checked into the PyCon-Tech code base in a month or two
(other projects are consuming my time these days).
http://us.pycon.org/TX2007/PyConTech
I optionally want models.py, views.py, forms.py, urls.py,
decorators.py, media/{js, img, css}/, templates/<appname>/,
templatetags/<appname>.py with some standard header information.
There are very, very few common threads between my models, and I would
prefer a graphical interface for the models, as a second stage in the
app building.
Of the 7 core apps for the conference software, no two share a common
model structure:
https://svn.python.org/conference/django/trunk/pycon/
I was being a little disingenuous when I said I didn't want most of
it. I don't want a text based model builder.
The tool I have is a small wxpython app. A friend and I were thinking
of turning it into a django app with an ajax model builder. I'm an old
OMT hack and it appeals to me, but the recursive nature of it gives me
a migraine.
On the serving of static media:
I have a custom django app (called appmedia) which deals with serving
up static content in the 'media' directory of any app if its the dev
server, otherwise it is up to apache or httplight to serve up media in
production. (and adds {% app_media_root "myapp" %} ) so there is no
need for me to serve up media local to the apps urls.py
This goes against one of the django style rules, but I feel its
cleaner.
> I've started re-working mine based
> purely on my own crazy preferences and habits. For example, if I add
> an attribute to a class called "name", it assumes it's a CharField
> and it also adds a SlugField called "slug"... I didn't know they
> existed till today. If I add an attribute called "url"... you can
> guess where that one is going..
I like the Idea of it, but I am concerned you will end up with a meta-
model language once you get everything done. As long as you don't go
too crazy with it, it should be fine.
> I'd love a call like this...
>
> >>> python startapp.py my_app_name -flavour=(tom | doug | malcolm |
> james )
My first implementation used something like the flavor you propose (I
made the mistake of calling it -type).
I had 4 spec'd out, and discovered that NONE of my 25 some odd apps
actually conformed to any of the 4 specs.
I think this was due to my purist mind conflicting with the reality of
the apps I wrote.
Someone other than me will hopefully be able to find some reoccurring
patterns that actually reoccur.
-Doug