We Keep Coding

Deploying django application in production?

I have installed Django and mod_wsgi-express (the new way) on an ubuntu 15.10 server using:
pip install Django
pip install mod_wsgi
Currently I am starting/deploying my django application using a script that:
cd ~/.local/bin
./mod_wsgi-express start-server ~/mysite/mysite/wsgi.py
where my application is located in (as a git repository):
~/mysite/
Since ~/mysite/ is not on the PYTHONPATH I have modified the wsgi.py file to:
import os
from django.core.wsgi import get_wsgi_application
# Hardcode the path to the application/add it to the PYTHONPATH
import sys
path = '/home/user/mysite'
if path not in sys.path:
sys.path.append(path)
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "mysite.settings")
application = get_wsgi_application()
This works fine for now. But if I want to use this in production I see some problems:
wsgi.py contains hard coded path to the django web application to make sure its in the PYTHONPATH. Further its not guaranteed to be in the same path on the local developer machine. At least an improvement could be to use relative paths.
The web application is distributed as a git repository. E.g. in java you would package it into a war or an ear file.
Both django and mod_wsgi-express are located in the ~/.local folder for a specific local user.
Are there any obvious changes I should start looking into to eliminate bullet 1-3 above or is the above approach more or less how django deployment works?

I'll start out by saying that I'm assuming you're using the set up you describe for specific reasons and I won't try to steer you towards anything that might be more admin-friendly. If you're not and could use a friendly nudge, you can try Googling around for different people's pros/cons and examples or I would put in a good word for Gunicorn and an LTS version of Ubuntu.
Anyway.
When I was reading your question the first thing that popped into my head was that you could use something like Fabric or even just a deployment script that could do a string substitution in your wsgi.py file, putting in the correct path for you along with handling everything else in your deployment. I would say automated deployments are something of a standard and you might like the freedom of being able to throw out a server and spin up a new one in 5 minutes, but they can be a lot to learn if you're doing other things at the time.
Figuring that you probably didn't want to mess with all the automation rigmarole, I then popped over to Django's mod_wsgi deployment documentation (which is pretty good) because messing around with the Python path seemed weird and like something you shouldn't have to do. Sure enough, they recommend running mod_wsgi in daemon mode, which gives you an opportunity to set the Python path in the Apache config and keep it separate from the code you distribute. Then you can just have different boxes use different config files based on their needs.
That same documentation has notes on using a virtual environment (virtualenv) which you also want to probably do -- that virtualenv would then be portable and would handle your concerns with point 3.
With point 2 you should probably just think of the git distribution as a feature -- no need to run a build process and upload WAR files and all the etceteras. Java people only put up with that because they theoretically get something from having their code compiled into bytecode; Python, for better or for worse, doesn't do any compilation so you can deploy your code transparently and use git to handle your files at all points in the application's life without worrying about keeping the artifact versions straight and all that.
EDIT:
You could also probably avoid any issues with PYTHONPATH by adding your ~/.local/bin folder to your path (export PATH=~/.local/bin:$PATH from command line) and then cding into your site's directory and just running mod_wsgi-express start-server mysite/wsgi.py. By adding the local bin folder to your PATH you gain the ability to reference any applications in it implicitly from any directory while still having everything rooted in the directory you cd into, which should keep Python from getting confused.
I would still prefer to link mod_wsgi into your main Apache installation and run it in daemon mode so that you can control bringing it up/down from systemd/systemctl instead of forking processes from your terminal and having to look up the process ID in ps to kill it.

Better something like this:
import os
import sys
sys.path.append("add/Your/Path")
os.environ.setdefault("DJANGO_SETTINGS_MODULE","mysite.settings")
import django
django.setup
import django.core.handlers.wsgi
application = get_wsgi_application()
application = django.core.handlers.wsgi.WSGIHandler()
check that You project is named a mysite, If You project have other name change mysite on name of You django-project. You will use to production apache?

import os
import sys
sys.path.append("add/Your/Path")
os.environ.setdefault("DJANGO_SETTINGS_MODULE","mysite.settings")
import django
django.setup()
import django.core.handlers.wsgi
application = get_wsgi_application()
application = django.core.handlers.wsgi.WSGIHandler()

Where is Flask running from on my OS X machine?

I'm used to building my websites with PHP, and on my OS X machine I expect to have to ensure that I have my scripts living in an explicitly specified location that I define as my Apache server's document root. But when I follow the simple instructions for building a Flask website, I magically get a working website, with nothing at all in any of the places on my machine that serve as document roots, regardless of where I have my Flask script. This is especially confusing since I always think if deployment as involving careful duplicating the file structure of my site under document root on the deployment server's document root.
Where is Flask "running from" on my OS X machine? Where do I "put it" when I deploy it (and what to I put)?

It's running from wherever you put it. You surely know where you saved the code: that's where it is.
But your mistake is in thinking that this development environment is running through Apache, or indeed has anything to do with how you'll run it in production. Neither is true. You're using a development server, the separate Werkzeug project, but that is not suitable for running in prod.
When you are ready to deploy, Flask has full instructions on how to either connect it to Apache through mod_wsgi, or set up a separate WSGI server which you'll usually connect to through a reverse proxy such as nginx.

Supposed you have your main.py under /path/to/my_project/, when you run the internal server python main.py, Flask is then running under your project folder.
Of course that built-in server is only good for development, when you're trying to deploy for production, normally Gunicorn (via wsgi app, read more HERE) or other web server is more appropriated (and advised by Flask) itself. And your production folder can be placed wherever you want, just like Apache PHP you may place your folder under /var/www/ (EDITED: as Daniel Roseman pointed out, you may try to change this folder location for security concern), it's the same for Flask, that's nothing stops you placing the folder but rather have the permission set properly.
Hope this helps.

Can Sentry be run under passenger WSGI (dreamhost)

I am trying to get sentry running on my dreamhost server. Dreamhost uses passenger wsgi to serve python frameworks, like django. I am able to get django apps running.
I am using virtualenv and I install sentry using pip, so all the code for sentry sits under the virtualenv directory. The instructions given for sentry doesn't use the startproject to create a directory that you can place somewhere for the passenger_wsgi.py file to find.
The sentry website gives examples of the program running under Nginx and uWSGI, but I am limited to (in this case) to apache and passenger wsgi.
Is it possible to run sentry under dreamhost's configuration and if so how does one pass things in like the config file to get it working. I have been able to locally start and interact with sentry, using :
sentry --config=/home/user/.sentry/sentry.conf.py start
so I know that all the dependencies are present on the host system

OK it looks like I was over thinking it, I forgot from a python perspective the file wsgi.py (which is found in the sentry directory) is called as sentry.wsgi when imported as a module. I was confused by sentry being a module that was downloaded from pip and how to access it. This is the reduced solution that works:
passenger_wgsi.py
import sys, os
INTERP = "/home/user/.virtualenv/sentry2/bin/python"
if sys.executable != INTERP:
os.execl(INTERP, INTERP, *sys.argv)
os.environ['SENTRY_CONF'] = "/home/user/.virtualenv/sentry2/sentry.conf.py"
import sentry.wsgi
believe it or not, that's it. If you look at the wsgi file in the sentry directory under the virtualenv install you will see it does all the importing of the django.core.handlers.wsgi and kicks off the correct application.

Run App Engine development server with modules in PyCharm

Since the latest release of the Google App Engine Python SDK, it's possible to use modules. I have a Python application with a default module and another module. To start the module in the development server, the development server has to be run like this:
dev_appserver.py app.yaml othermodule.yaml
When I add app.yaml othermodule.yaml to "Additional options" in the Run/Debug configuration of PyCharm and then run the development server, I get the following error message:
google.appengine.tools.devappserver2.errors.InvalidAppConfigError: "."
is a directory and a yaml configuration file is required
This is because PyCharm adds a dot at the end of the command to run the development server, like this:
dev_appserver.py app.yaml othermodule.yaml .
Is it possible to remove the dot, or do I have to wait until this is fixed in PyCharm? Before there were modules, there was no need for this.

You can go around this for the time being by just creating a new Run Configuration.
Chose Python configuration, then fill like this:
script: /path/to/your/dev_appserver.py
script parameters: dispatch.yaml module1.yaml module2.yaml
working directory: /path/to/your/appengine/project
It works just fine like this for me. The dispatcher is launching properly and I've got all the logs like before in PyCharm.

Files being served are stale / cached ; Python as fcgi + web.py + nginx

I'm serving files in ubuntu using Nginx and fcgi, python and web.py. My index.py contents are:
app = web.application(urls, globals(), True)
if __name__ == "__main__":
web.wsgi.runwsgi = lambda func, addr=None: web.wsgi.runfcgi(func, addr)
app.run()
And I'm launching with:
spawn-fcgi -n -d /usr/share/nginx/www -f ~/Projects/index.py -a 127.0.0.1 -p 9002
Which works fine, EXCEPT, once I make changes to the source files (index.py or any class it includes), those new files are never loaded. I have to stop spawn-fcgi and restart it to see any changes. This make development very cumbersome.
In addition I've turned off the generation of python .pyc/cache files.
TIA

I deploy my apps using nginx+uwsgi or apache+mod_wsgi, both of them reload app if I touch code.py. But I run apps from integrated server when developing.
If running web.py integrated server in development mode that has its own reloader is not an option then the only option is to write your own dispatcher with reload functionality.

That is most likely by design.
You do normally not want modules reloaded in a production environment (performance, and due to the fact that a module reload in Python does not always have the intended effect).
For development, use some other simpler server model (for example, Django provides its own development server for this exact purpose, I have not used webpy but it appears to have the same functionality according to the tutorial). Use nginx only when deploying the webapp, not in your development environment.
You should not have to bother about .pyc files under normal circumstances (exceptions are in some problematic NFS setups, or when .pyc files are created by the wrong user with the wrong permissions).