-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Brett,
On 10/12/2011 06:31 PM, Brett H wrote: > 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. I do understand the desire to have startproject play nicely with other tools (like distutils2, or VCS') that may want to create an outer directory themselves. And I also understand that not everyone cares to keep the sys.path-added directory isolated from other things, so many people will want manage.py directly in the outermost containing directory. My concern is that the default behavior of startproject should do something that is experimentation-friendly and beginner-friendly, and I don't think dumping multiple things into the CWD is either of those. I think that you should be able to just try out startproject and get something sensible and workable right off the bat, without having to first understand distutils2 or why you should use a VCS, or read the docs carefully to find out that you really should create an outer directory yourself first manually before running it. So I think it makes sense to (as a separate feature) make startproject flexible enough to work with pre-existing directories, for more advanced users who want that flexibility, either via the two-argument extension or ptone's patch. But I still think the best default behavior is to contain all our output under a single provided name, not dump into the CWD. > 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. As I said before, I think that some type of Django integration with distutils2 is an interesting idea and worth exploring, but I think it belongs in third-party extensions for quite some yet before it should be considered in core. > 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. Hear hear! Couldn't agree more with all of this. The only part I don't understand is if you're drawing an equivalence between "startproject containing its output by default" and "Django creating a new wheel" - that seems like a bit of a stretch :-) Thanks for your thoughts! Carl -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6WOQoACgkQ8W4rlRKtE2dR1wCfesxGqxvN1TOZIjJa16TO+5TY eBsAoJTOfucTz41agwkeDxMFCRAezqlb =fG0n -----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 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.
