I would like to know if there is a best practice for the structure of Django projects.
In particular, where do you located the virtualenv folder for your project?
Do you think is better the following solution:
/myproject
/myenv
manage.py
/mysite
settings.py
urls.py
wsgi.py
__init__.py
Or do you think is better to have a folder with all environments, for example in the home directory:
/virtualenvs
/myproject1_env
/myproject2_env
...
/myprojectN_env
I like to use virtualenvwrapper to keep my virtualenv at the same place and easily access them. I can recommand you to use this :)
Features
- Organizes all of your virtual environments in one place.
- Wrappers for managing your virtual environments (create, delete, copy).
- Use a single command to switch between environments.
- Tab completion for commands that take a virtual environment as argument.
- User-configurable hooks for all operations (see Per-User Customization).
- Plugin system for more creating sharable extensions (see Extending Virtualenvwrapper).
I have no relation with this project, I just use it on daily basis and really like it. Hope it can help you :)
Yup, using virtualenvwrapper is the best practice to manage your project without interfering with your machine environment it's like creating your own environment or machine you can say.
I think Django has provide the best structure as we use daily without any interruption not even mentally and it's easy to handle, Everything is separated so well.
Yes and you can have many aaps under one project which may or may not be connected to each other depends on your requirement , configuration of all app under one project will be in settings.py which is in parent folder for all apps.
Basically it's awesome what they have provided.I will suggest you to use default hierarchy, doesn't matter even if your working with big or small project.
Related
In our django project we've created quite a bit of custom management commands over time. All of these are nested under:
root/<app_name>/management/commands/<command_name>.py
The management directory contains just an __init__.py and the commands directory ( as specified in the docs).
This seems like unnecessary nesting to me.
Are there any other uses for the management directory that I'm not aware of?
You won't get direct answer for that, but here are few things I collected:
Namespaces are one honking great idea -- let's do more of those! - The Zen Of Python
Future features can be added without the pollution of the root directory.
Makes your project organized(actually forces you, so if you are new user, you get a nice structure. You can put your own logic in management)
If you search on the web you'll find people saying that you should put your signals in the management directory.
Seems you can use management.py rather than a directory like django built-in sites app.
I would like to install a djangopypi server for our local development and deployment. However, I'm slightly confused about its installation docs. Apparently, it's assumed that djangopypi is installed inside a bigger project as an app, which is at least debatable from my point of view. I would like my local PyPI instance to run independently of anything else, as a "normal" web service.
And this is where I'm lost. It seems I need some kind of a minimal Django project to wrap djangopypi, which seems a bit overkill for me. Is there a more elegant way to install it in standalone mode?
That's exactly what you need. djangopypi is just an app. Like any Django app, it needs to know stuff like how to connect to your database, etc. That information comes from the project. It doesn't provide this for you because there's no way it could possible know what the best settings are for your particular environment; that's your responsibility.
So, no, it's not "overkill". It's the bare minimum required for functionality, and it's just the way things are. Create a simple project, change all the relevant items in settings.py, nclude djangopypi's urls.py in yours, and you're done. Is is really that hard?
In a large Django project, I have several evil monkey-patching hacks to execute at application startup time. However, I don't quite see a correct place for such hackery: neither urls.py nor settings.py nor manage.py seem fit for this. Where would you recommend I put those?
In python you will always come across initialization. That's why its always better to use init for initialization. Even in django when you create a project it must have an init.py in it.
I usually put all my initialization in __init__.py its a safe and clean way. You can do the same rather than create another initialization module.
There isn't really a good answer to this question at the moment. There's a Summer of Code project at the moment to rewrite the app loading process, which hopefully will include hooks for initialization code.
In the meantime, I think the best place for this is in urls.py. The admin application and Haystack both do it there, and it seems a good pattern.
I've just started using Django and one thing I find that I'm doing is starting a lot of new projects. I'm finding this process to be pretty tedious every time, even using manage.py startproject * I'm constantly changing settings in settings.py like media_root and template paths. Just a little background, I come from PHP and CodeIgniter. I never used a stock CI directory. I modified it to meet my needs for a new project. When I needed a new project, I would just copy that directory. manage.py seems to generate the files on the fly so this approach doesn't seem that possible. Does anyone else have any advice on this?
Lincoln loop has some best practices, they suggest importing settings from a different file. http://lincolnloop.com/django-best-practices/projects/modules/settings.html
Also checkout pip requirements, you might be able to use this to install the settings module from an external source like a git repo.
I'm using Paver to automate my Django project setup.
I have a Bitbucket repository with my own bootstrap setup. Eventually I'll make this generic, but for now it might give you some example code
Sounds like you're starting new projects very often. I assume that's because you're learning. Sure, if there's a custom settings.py that will save you some typing as you generate your learning projects, create it and use it. You could make your template the whole project directory, but since you're unlikely to have a lot of project-level boilerplate outside of settings.py, just focus on that one file. The settings file is the essence of the project.
Django development is all about apps. As you learn more, apps will start to become your focus. My advice would be not to pour too much energy into making an efficient assembly line for project creation.
Also, please learn and use use version control. For bonus points, also learn and use virtualenv :)
If you were to write an app for a site, but wanted to make the app plug&play so you can just drop it in any Django project, set the main URL and there you go, how would you do that if you wanted to keep all the other required utility apps included in your portable app.
Example:
site/
site/site-app1
site/templates/site-app1
site/util-app1
site/util-app2
site/util-app3
Note: that the site-app1 makes the use of all three util-apps. It works great in this manner. But now, you decide to send the app to someone, but just that app with all its dependencies.
If we could package and send the apps like this?:
site/site-app1
site/site-app1/template
site/site-app1/util-app1
site/site-app1/util-app2
site/site-app1/util-app3
Then you just send site-app1 and everything goes with it.
Is there a way to make portable with utility apps as subdirctories?
Note: the idea is that we don't want to send the whole project, but one site-app within
the project only.
There have been a few presentations about reusable django apps, so search around. These should get you going:
Developing reusable apps. pdf and video
Django Templates: The Power of Inheritance
The presentations #Gerry links to are good sources of general info. To answer your question more directly, there isn't a way to package one app inside of another one (EDIT sorry, this is just plain wrong. You can put one app inside of another one's namespace, and it works just fine. It's an odd thing to do though: you're implying that the one app is a part of the other one; if that's true they'd be easier to use as a single app. So I'd still recommend one of the below options). AFAICT your options are:
If possible, make those external dependencies optional (i.e. enhanced functionality if util_app1 is available, fallback behavior if it isn't). This is how many apps behave with respect to, say, django-tagging or django-mailer.
Roll all the functionality into a single app. Depending how much code you actually depend on from the utility apps, if the dependencies are absolutely necessary for your app to function, this might be the best option to make things easy on your users.
Package and distribute all the apps separately and note the dependencies both in the documentation and in the setup.py install_requires. If all the apps are independently useful, this approach may be best. If they aren't all independently useful, why are they all separate apps?
Django applications can be made portable by adhering to certain practices. Ofcourse, these are not mandated
Application Location
The convention is to add applications in an apps/ directory, and to modify the manage.py (and eventually the apache config) to include
import sys
from os.path import abspath, dirname, join
PROJECT_ROOT = abspath(dirname(__file__))
sys.path.insert(0, join(PROJECT_ROOT, "apps"))
Your directory structure will look something like
site
site/apps/
site/apps/app1/
site/apps/app2/
Templates
Templates are located in the templates directory in the application. The convention is not to force the user to copy them in any other location. Eventually the user can have global templates to override the ones in the application.
Settings
Keep all default settings in a local file within the app directory. The settings would be overridden by the global settings. The local settings file will have the following structure..
from django.conf import settings
def get(key, default):
return getattr(settings, key, default)
SETTING_1 = get('SETTTING_1', 10)
These conventions should cover most major issues.