I'm uploading my first Django project to a Linux server, where I should put my project in the filesystem?
With a PHP, or ASP project, everything goes into /var/www, would it be ok to do the same and add my Django project to the /var/www folder?
In the Django tutorial it states:
Where should this code live?
If your background is in PHP, you're probably used to putting code under the Web server's document root (in a place such as /var/www). With Django, you don't do that. It's not a good idea to put any of this Python code within your Web server's document root, because it risks the possibility that people may be able to view your code over the Web. That's not good for security.
Put your code in some directory outside of the document root, such as /home/mycode.
File Hierarchy System
#Andy Hayden really states where not to place ones code. The File Hierarchy System (FHS) implicates the following structure; PATH maps to PACKAGE or PROVIDER (It is recommended that parties providing multiple packages should use PROVIDER/PACKAGE) :
/etc/opt/PATH # FHS location for /opt configuration files
/opt/PATH # FHS location for PROVIDER or PACKAGE name
/var/opt/PATH # FHS location for /opt variable storage
The FHS expects /opt/PATH to contain all the material necessary for the successful execution of ones package so it seems prudent to setup the following symbolic links
/etc/opt/PATH to /opt/PATH/etc
/var/opt/PATH to /opt/PATH/var
This provides a good basis but Django projects have extraneous requirements that the above structure does not fully meet.
Static Files
Static files are deployed when one runs python manage.py collectstatic to the STATIC_ROOT which should point to the web server root for static delivery, usually /var/www/PATH.
One could link /var/www/PATH symbolically to /opt/PATH/static
but this is typically a bad idea; Consider the case that you have a misconfigured server and a user goes to www.domain.tld/../ and copies your work.
Settings
If you created your project with django-admin create-project WEBSITE the you will typically have a setup.py file under the WEBSITE folder.
PROJECT/
WEBSITE/
setup.py
...
If you converted this settings module into a package, or you used some wrapper around django-admin e.g. django-cms-create etc.
PROJECT/
WEBSITE/
settings/
__init__.py # from .settings import *
settings.py
...
You might symlink /etc/opt/PATH to /opt/PATH/WEBSITE/settings instead of /opt/PATH/etc as described above. I can't think of a practical reason for doing so though... YMMV.
Media
Media, typically provided by ones websites users, are placed into MEDIA_ROOT. It seems prudent to map /var/opt/PATH to /opt/PATH/media in this case.
Virtual Environments
/opt/PATH/env seems the most logical location. /var/env/PATH also seems sensible but is probably better suited as a symbolic link to /opt/PATH/env.
Since a virtual environment is neither an application nor a library the locations /opt/bin and /opt/libs would not do for this. /env/ or /pyvenv/ does not conform to the FHS.
Whiskey
If you're using mod_wsgi with Apache the an invocation similar to python manage.py runmodwsgi --server-root /etc/opt/PATH --setup-only is probably preferable since it places the Apache control commands into the FHS compliant locations, granted they are more cumbersome to invoke in this case.
Home
To my understanding /home was traditionally used by PHP developers when they were hosting multiple sites upon the same server. If you're using Django you're probably serving your site from a dedicated machine and this structure looses a bit of favour in this case... YMMV.
Related
So I have this Python pyramid-based application, and my development workflow has basically just been to upload changed files directly to the production area.
Coming close to launch, and obviously that's not going to work anymore.
I managed to edit the connection strings and development.ini and point the development instance to a secondary database.
Now I just have to figure out how to create another copy of the project somewhere where I can work on things and then make the changes live.
At first, I thought that I could just make a copy of the project directory somewhere else and run it with different arguments pointing to the new location. That didn't work.
Then, I basically set up an entirely new project called myproject-dev. I went through the setup instructions:
I used pcreate, and then setup.py develop, and then I copied over my development.ini from my project and carefully edited the various references to myproject-dev instead of myproject.
Then,
initialize_myproject-dev_db /var/www/projects/myproject/development.ini
Finally, I get a nice pyramid welcome page that everything is working correctly.
I thought at that point I could just blow out everything in the project directory and copy over the main project files, but then I got that feeling in the pit of my stomach when I noticed that a lot of things weren't working, like static URLs.
Apparently, I'm referencing myproject in includes and also static URLs, and who knows where else.
I don't think this idea is going to work, so I've given up for now.
Can anyone give me an idea of how people go about setting up a development instance for a Python pyramid project?
The first thing you should do, if it's not the case, is version control your project. I'd recommend using git.
In addition to the benefits of managing the changes made to the application when developing, it will aldo make it easier to share copies between developers... or with the production deployment. Indeed, production can just be a git clone of the project, just like your development instance.
The second thing is you need to install the project in your Python library path. This is how all the imports and includes are going to work.
I'd recommend creating a virtual environment for this, with either virtualenv or pew, so that your app (and its dependencies) are "isolated" from the rest of your system and other apps.
You probably have a setup.py script in your project. If not, create one. Then install your project with pip install . in production, or pip install -e . in development.
Here's how I managed my last Pyramid app:
I had both a development.ini and a production.ini. I actually had a development.local.ini in addition to the other two - one for local development, one for our "test" system, and one for production. I used git for version control, and had a main branch for production deployments. On my prod server I created the virtual environment, etc., then would pull my main branch and run using the production.ini config file. Updates basically involved jumping back into the virtualenv and pulling latest updates from the repo, then restarting the pyramid server.
I am following a step-by-step tutorial blog on the flask micro framework for python.
I bumped into an issue, when they require me to 'setup' a configuration file in the root of the application folder, so it can easily be accessible if needed.
They called it config.py.
My question is, if the local path to my application is /home/test/application1/, should I create the file inside the ./application1/ directory? What gets me confused in this somewhat obvious question is that I did a quick search for other config.py files in the local directory inside /home/test/application1/, where I found 4 other files. There were in the following directories:
/home/test/application1/flask/lib/python2.7/site-packages/flask/testsuite/config.py
/home/test/application1/flask/lib/python2.7/site-packages/flask/config.py
/home/test/application1/flask/local/lib/python2.7/site-packages/flask/testsuite/config.py
/home/test/application1/flask/local/lib/python2.7/site-packages/flask/config.py
So should I create a new config.py file in the directory that I first mentioned or should I add some lines in one of the previously created config.py files.
Here is the source of the step-by-step tutorial:
It is at the beginning, right after Configuration.
Unlike other frameworks, Flask does not have a lot of rules, in general you can implement things in the way they make sense to you.
But note that the other config.py files that you found are all in the virtual environment, and are all scripts that come with Flask. They have nothing to do with the application configuration.
I wrote the tutorial you are following. In the tutorial I'm putting config.py outside of the application package. This is what I like, I consider the configuration separate from the application. My thinking is that you should be able to run the same application with different configuration files, so that for example, you can have a production configuration, a testing configuration and a development configuration, all different.
I hope this helps.
I have a django project which I want to deploy on apache2 Http Server.
However, I want to automatically copy all the python files from some directory to apache srv directory which is /srv/www/myproject. Is there any automatic python tool which could solve the purpose.
I have looked into DistUtils and setup.py but I am unsure about how I would copy all .py files (along with directory structure) to the apache directory.
Any help will be appreciated!!!
Take a look to fabric, it is a great tool to do automatic deployments
From the django tutorial:
If your background is in PHP, you're probably used to putting code
under the Web server's document root (in a place such as /var/www).
With Django, you don't do that. It's not a good idea to put any of
this Python code within your Web server's document root, because it
risks the possibility that people may be able to view your code over
the Web. That's not good for security.
Put your code in some directory outside of the document root, such as
/home/mycode.
For copying files, you can use something as simple as FTP/SCP which you can automate; or you can use more full blown deployment options like fabric (see this blog entry for a step-by-step guide on fabric + virtualenv + apache mod_wsgi).
You can use any tool to automate the task; but please put the code in the appropriate non-web browsable directory.
As the title states, I'm trying to figure out the best practice for where to store application files for a Python website on the server. Document root, or no?
I come from a land of PHP. :)
EDIT - To that end, links to any material describing the best practice differences between Python and PHP are hugely appreciated.
No. WSGI containers don't require the scripts to be in the document root, and so to increase security in case of a transient server error they shouldn't be placed in the document root.
There's no reason to store it in the document root.
While storing the app in the doc root isn't nessescarily a security problem - if configured correctly and handled carefully - storing it outside will remove a lot of headache and configuration work.
That's the main reason not to do it.
I personally use https://bitbucket.org/acoobe/django-starter/ layout with buildout. So developed apps goes to apps folder and just used apps goes to parts/eggs folders (parts for packets from git, mercurial or svn and eggs for pypi located apps).
So the answer is NO. Everything should be placed in separate tidied folders. All your server need to know were is wsgi script and where is var dir. Well just like everyone else here said.
Everything has been said I think, so I will only elaborate a bit. Here is an explanation of how Apache maps URLs to files on disk: http://httpd.apache.org/docs/2.2/urlmapping.html. As you can see, the base rule is that only the files within DocumentRoot are exposed to the outside world. You can change that by doing the explicit import of other files or folders using e.g. Alias directive.
Now, you obviously don't want your Python scripts to be exposed to everyone - which means that you should keep them outside DocumentRoot and any other folder "imported" to DocumentRoot (using e.g. the mentioned Alias directive). What you want to do instead is to merely hook given URL to your Python program - if you use mod_wsgi, this can be done with WSGIScriptAlias directive. In other words, you should map the effects (result) of your script to given URL, instead of mapping the files themselves.
So - where you should keep your Python files? I would say it's a matter of personal taste - some people advise to not keep them in user folder (i.e. /home/xyz/) because e.g. Apache configuration flaw may expose user folders to the outside world. What's left? E.g. /usr/local/, /var/www - there's really no magic in picking home folder for your scripts.
I am in a team developing a web-based university portal, which will be based on Django. We are still in the exploratory stages, and I am trying to find the best way to lay the project/development environment out.
My initial idea is to develop the system as a Django "app", which contains sub-applications to separate out the different parts of the system. The reason I intended to make these "sub" applications is that they would not have any use outside the parent application whatsoever, so there would be little point in distributing them separately. We envisage that the portal will be installed in multiple locations (at different universities, for example) so the main app can be dropped into a number of Django projects to install it. We therefore have a different repository for each location's project, which is really just a settings.py file defining the installed portal applications, and a urls.py routing the urls to it.
I have started to write some initial code, though, and I've come up against a problem. Some of the code that handles user authentication and profiles seems to be without a home. It doesn't conceptually belong in the portal application as it doesn't relate to the portal's functionality. It also, however, can't go in the project repository - as I would then be duplicating the code over each location's repository. If I then discovered a bug in this code, for example, I would have to manually replicate the fix over all of the location's project files.
My idea for a fix is to make all the project repos a fork of a "master" location project, so that I can pull any changes from that master. I think this is messy though, and it means that I have one more repository to look after.
I'm looking for a better way to achieve this project. Can anyone recommend a solution or a similar example I can take a look at? The problem seems to be that I am developing a Django project rather than just a Django application.
The best way that I have found to go about this is to create applications and then a project to glue them together. Most of my projects have similar apps which are included in each. Emails, notes, action reminders, user auth, etc. My preferred layout is like so:
project/
settings.py
urls.py
views.py
...
apps/
emails/
urls.py
views.py
...
notes/
urls.py
views.py
...
...
apps:
Each of the "apps" stands on its own, and other than a settings.py, does not rely on the project itself (though it can rely on other apps). One of the apps, is the user authentication and management. It has all of the URLs for accomplishing its tasks in apps/auth/urls.py. All of its templates are in apps/auth/templates/auth/. All of its functionality is self-contained, so that when I need to tweak something, I know where to go.
project:
The project/ contains all of the glue required to put these individual apps together into the final project. In my case, I made use heavy of settings.INSTALLED_APPS in project/ to discern which views from the apps were available to me. This way, if I take apps.notes out of my INSTALLED_APPS, everything still works wonderfully, just with no notes.
Maintenance:
This layout/methodology/plan also has long-term positive ramifications. You can re-use any of the apps later on, with almost no work. You can test the system from the bottom up, ensuring that each of the apps works as intended before being integrated into the whole, helping you find/fix bugs quicker. You can implement a new feature without rolling it out to existing instances of the application (if it isn't in INSTALLED_APPS, they can't see it).
I'm sure there are better documented ways of laying out a project, and more widely used ways, but this is the one which has worked best for me so far.
You should take a look at :
Django generic relations
Django reusable apps best practices if you want to re-use
GIT or any other CVS (git is great for maintaining + deployment)
Fabric if you need automated deployments/updates
I usually use this project structure :
/djangoproject
/apps
/main # the main code
/static # each sub app can serve statics
/app1
/static # each sub app can serve statics
/app2...
/scripts # manage.py, wsgi, apache.conf, fabfile.py...
/core # your libraries ...
settings.py
local_settings.py
Each app in /apps have an urls.py thats autoincluded in the main urls.py. And each app can be a git submodule (or svn external)
Also, using git, you can work on different parallels branches (master/dev/customerA/customerB...) and merge updates.
Creating real reusable is not so easy with django.
You can extract the common functionality into a separate module and make your apps depend on it:
my_portal
auth_module
profiles_module
application1 (depends on auth_module)
application2 (depends on auth_module and profiles_module)
I think the fact that a 'classical' Django project appear to 'contain' the apps it's using prevent you from seeing the picture - in fact, it's not necessary. For a project where you're going to have some sort of pluggable modules I'd suggest organizing the apps as eggs and using zc.buildout+djangorecipe to manage everything.
This way you'll be able to keep your modules in a flat one-level structure. Eggs have the ability to specify dependencies, so if you install application1 (see above), auth_module will be installed automatically.
Also it'll be easy to have different configurations deployed to different servers. Suppose, you have server1 which has application1 installed and server2 which has both application1 and application2 installed - you can just have two configs:
server1.cfg:
[buildout]
extends = base_deployment.cfg
eggs += application1
server2.cfg:
[buildout]
extends = base_seployment.cfg
eggs += application1
application2
djangorecipe also allows you to specify different settings files for each buildout config so you'll be able to add the necessary bits to the main project's urls and installed apps settings.
Not to mention, you can also have a separate config for development configuration (with debug=True and Django Debug Toolbar installed, for example).