Hi all, my name is flo, i am relatively new to django but would consider myself an experienced web developer. I am sorry if this has been asked hundreds of times, but after doing somewhat extensive research i still would like to gain some insight into the design decisions involved in how manage.py and the project path structure is set up by django. I found that django is a very well-designed toolkit in every aspect i researched so far, but this is the only area where i still scratch my head and miss the clarity and state-of-the-art-ness found in all other areas of django.
If i get it right, manage.py adds the parent path of its location in the file system to the pythonpath (actually this is done in django.core.management.setup_environ() by calling sys.path.append (os.path.join(project_directory, os.pardir))). This results in a comfortable initial way of experimenting with django. However, i found that it does not actuall give me a full pythonpath in the parent folder - if i add additional packages there, i have to explicitly set the --pythonpath parameter when calling manage.py to the parent dir of manage.py. Furthermore, another feature that supposedly should help newbies makes things even more complicated: the folder that manage.py is in is also somehow treated as a part of pythonpath, so that packages can be referenced in the source starting from the root package (mysite.myapp) or as a relative path (myapp). This "helps" local development for a kick start, but mayhem breaks loose once you transfer your code to a different environment where the project is not launched through manage.py. Another strange side effect is that i cannot name my source directory (the one above "mysite") "django" (which would be my personal preference) because, for some reasons i could not clearly resolve, this causes a conflict with the main django namespace, although the pythonpath should start *inside* this folder. It would be great if somebody more experienced (which i guess most of you are) could fill me in with the reasons for this design and clarify the concepts working under the hood so that i can build a clear mental model of how pythonpath et al. is set up - on the local development machine and on a server environment. In the case that all this is not following a concept as clear as the rest of django, i would personally vote for refactoring the setup in a way that hints newbies in a more deployment-friendly way of setting up their projects from the beginning, instead of causing refactoring troubles later on. All the best and thanks to creators and contributors for a great framework! flo ledermann http://www.floledermann.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
