On Wed, Oct 12, 2011 at 9:23 PM, Carl Meyer <c...@oddbird.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Russ, > > On 10/12/2011 05:14 AM, Russell Keith-Magee wrote: >> My only feedback on the patch is a point of clarification in the >> tutorial. Rather than creating a mysite directory with a mysite >> project directory in it, and then having to refer to the "inner/outer >> directory" or "the directory with manage.py in it", it strikes me that >> it might be cleaner to name the outer directory something generic >> (like "django_tutorial"). This reinforces that the outer directory >> name doesn't matter, and that startproject is only creating the inner >> directory. > > So the repeated directory name does make the tutorial wording slightly > clumsy (though I don't think it's much of a problem otherwise). The > issue is that startproject _does_ in fact create both the outer and > inner directory; and I think it must do so, else its creating a > manage.py in the current directory, and we have to explicitly tell > people "first create an empty directory, then run startproject inside of > it" - I don't think that's a good plan.
I'm not convinced it's a bad idea. From an pedagogical perspective, it's easy to explain -- Make a directory to contain all the bits for your project, move into the directory, then bootstrap your project. My only hesitation about this is that startproject wouldn't be namespacing it's own output -- this is akin to the problem of zip/tar files dumping their contents into the current working directory. However, we're only dropping 1 file -- manage.py -- and if overwriting manage.py is a concern, we could put protections on startproject so that it only runs on an empty directory (unless you specify a --force option or similar). > I toyed with ideas like allowing startproject to take two arguments > instead of one, or allowing its argument to be an invalid Python module > name, using that for the outer directory, and then doing an automatic > slugify-like conversion to a valid Python module name for the inner > directory. In the end I decided it was simplest to just live with the > repeated directory name. Agreed that extra arguments aren't needed. Duplicating the directory name is weird, but it's a one time thing, and can be easily renamed. > I suppose the one other thing we could do is explicitly have the user > rename the outer directory in the tutorial? This doesn't really seem > worth it, though... Yeah - this doesn't sound worth it. The only upside I can see is that it would really drive home the fact that it doesn't matter what the top level directory is called. However, it's something that we'd be teaching users to do for no reason other than to not confuse them -- but by putting it in the tutorial, it becomes "best practice". In the long run, it's probably better to avoid doing things like this. Russ %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
