Having reworked project structures so many times I think creating the outer folder 'site_root' with startproject is a bad idea. Making startproject install manage.py in the current working directory is the best transitional solution until distutils2 becomes stable.
Even though distutils2 is not ready for primetime, by python convention the outer folder IS the source distribution folder. Django can have many sites under one project, so conceptually site_roots are just distributions. Having been stung with setup.py or any .py file being in the outer directory I believe ultimately manage.py should be deprecated post 1.4 since ultimately all it does is save 3 keystrokes, and deal with path issues that could go away when replaced with a setup.cfg file and appropriate meta-data to locate the settings.py. Ultimately distutils2 was accepted into Python 3.3 so it will be the standard for installation, and so the python way for creating distributions will be `pysetup.py create [distribution]`[http:// docs.python.org/dev/install/pysetup.html] Since distutils2 is meant to be extensible pretty much like Django management commands, you should probably be able to have a Django installed pysetup command so that `pysetup.py create-django [distribution] --project=[different project name]` extends the pysetup.py create command and also creates the project in the same step. Of course as I said - distutils2 is a way off being stable and backported, and the documentation is not good enough, despite making it into python 3.3 alpha, so if people wanted an interim solution then having an additional django command such as `django-admin.py createdist [distribution] --project=[alt project name]` that created a minimal distribution folder with setup.cfg (the most minimal required to package), manage.py, and project structure in one command would I think be one way to do it. Having a separate createdist command would I think also allow creating default folders for templates, static, and media as part of that distribution, since I think ultimately pysetup.py should be able to install that django project distribution on a server, and play nicely with other installation tools. Logically some of the meta information about project layout required for installation might conceivably move to setup.cfg while retaining settings.py for actual non file-location settings, but baby steps are good. Since people love inventing their own weird and wonderful ways to organise things, startproject should I think remain a much more minimalist command that just creates the minimum to get going, and doesn't preconceive whether or where someone wants to have a site_root, templates or a kitchen_sink folder (except for the new manage.py). I think it's important that Django focus on not creating a new wheel when a lot of people are already working on fixing the existing packaging & installation wheel in other forums. As I said previously, the historical reasons for how django deals with python paths and finding package directories is there because the python methods sucked, but really django projects are no more special than any other python distribution with metadata, packages, data, docs, scripts, and sources. Brett On Oct 13, 11:21 am, Brett H <[email protected]> wrote: > +1 on installing CWD. Integrates nicely with the virtualenvwrapper > mkproject command. > > I have a much longer reasoning why startproject should not get into > creating the outer folder which is effectively the distribution > folder, and the domain of distribution packaging tools, so I'll follow > this post up. > > On Oct 13, 11:09 am, Carl Meyer <[email protected]> wrote: > > > > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > Hi Chris, > > > On 10/12/2011 05:28 PM, Chris Beaven wrote: > > > > Great job on getting the ball rolling on this, Carl! > > > > +1 on the whole idea > > > Thanks! > > > > Similar to what Russ and Luke are saying, I'd also prefer it if > > > startproject dropped manage.py and the project Python package in the > > > current working directory (with overwrite checks first). > > > I remain -1 on CWD pollution by default; I haven't yet seen any > > arguments in favor of it that I find even slightly convincing. > > > As we just discussed on IRC, I'd be happier to have an optional second > > argument to startproject, if this is really an issue. If two arguments > > were given, the first would be the containing directory name (which > > could also be "."), and the second the package name. (Could also do it > > in the other order, but I think putting the containing directory first > > feels more natural, as it's "first" in the hierarchy). > > > I'm also fine with ptone's patch to allow using an existing directory, > > which maybe addresses some of the same cases. > > > I think either one of these should be done as a separate follow-on > > patch, though, as I think they are mostly-orthogonal new features for > > startproject, not closely related to the purpose of this patch. > > > Carl > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.10 (GNU/Linux) > > Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/ > > > iEYEARECAAYFAk6WLCAACgkQ8W4rlRKtE2fK7wCgqnSaF8lHx0/bKcSIb4ElYEJ4 > > hdsAn27cKx/j+m0prV9Kz8MptfQR2Dj+ > > =GUEr > > -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
