We Keep Coding

How to set up a local dev environment for Django

Python web development newbie question here. I'm coming from PHP/Laravel and there you have Homestead which is a pre-configured Vagrant box for local development. In a so-called Homestead file, you configure everything such as webserver, database or PHP version. Are there any similar pre-configured dev environments for Django?
I already googled and there don't seem to be any official or widely-used Vagrant boxes for Django. The official Django tutorial even tells you how to install and set up Apache and your preferred database. This is a lot of work everytime you want to create a new Django project, especially if those projects run in different production environments. All the other tutorials I've found just explain how you set up virtual environments with venv or the like. But that doesn't seem to be sufficient to me. What you obviously want is a dev environment that is as close as possible to your production environment, so you need some kind of virtual machines.
I'm a little bit confused right now. Do you just grab some plain Ubuntu (or any other OS) Vagrant box and install everything yourself? Don't you use Vagrant at all but something else? Did I miss something and the Python web development workflow is completely different?

The typical local development in Django just uses the builtin web server and an SQLite database. The steps to get that up and running are:
Ensure you have the desired version of Python installed.
Create a virtual env to isolate libraries needed for your project from the rest of the system (this is optional by highly recommended, I'd actually recommend using Poetry).
Install Django, probably via pip.
Run manage.py runserver (and migrate the database and set up a superuser, yada yada).
That's pretty much it and sufficient for local development. What you need to be aware of is that some differences exist between SQLite and Postgres, MySQL etc., and if you hit the spots where the difference is important, you'll want to set up your targeted database as well to develop directly against it. That can probably happen in a Docker container if that makes sense for you. But there's little reason to put Django into a container during development, unless your project is especially complex and requires simulating certain conditions which the builtin server somehow can't.

Does this help?
$ python3 -m venv my_env # create your virtual environment
$ source my_env/bin/activate # Any package you install will be inside this environment
$ pip install -r requirements.txt # can also install packages indivdually
$ deactivate # get out of the isolated environment
Here's the doc

Deploy Django project using wsgi and virtualenv on shared webhosting server without root access

I have a Django project which I would like to run on my shared webspace (1und1 Webspace) running on linux. I don't have root access and therefore can not edit apache's httpd.conf or install software system wide.
What I did so far:
installed squlite locally since it is not available on the server
installed Python 3.5.1 in ~/.localpython
installed virtualenv for my local python
created a virtual environment in ~/ve_tc_lb
installed Django and Pillow in my virtual environment
cloned my django project from git server
After these steps, I'm able to run python manage.py runserver in my project directory and it seems to be running (I can access the login screen using lynx on my local machine).
I read many postings on how to configure fastCGI environments, but since I'm using Django 1.9.1, I'm depening on wsgi. I saw a lot about configuring django for wsgi and virtualenv, but all examples required access to httpd.conf.
The shared web server is apache.
I can create a new directory in my home with a sample hello.py and it is working when I enter the url, but it is (of course) using the python provided by the server and not my local installation.
When I change the first line indicating which python version to use to my virtual environment (#!/path/to/home/ve_tc_lb/bin/python), it seems to use the correct version in the virtual environment. Since I'm using different systems for developing and deployment, I'm not sure whether it is a good idea to e.g. add such a line in my djangoproject/wsgi.py.
Update 2016-06-02
A few more things I tried:
I learned that I don't have access to the apache error logs
read a lot about mod_wsgi and django in various sources which I just want to share here in case someone needs them in the future:
modwsgi - IntegrationWithDjango.wiki
debug mod_wsgi installation (only applicable if you are root)
mod_wsgi configuration guide
I followed the wsgi test script installation here - but the wsgi-file is just displayed in my browser instead of beeing executed.
All in all it seems like my provider 1und1 did not install wsgi extensions (even though the support told me a week ago it would be installed)
Update 2016-06-12: I got a reply from support (after a week or so :-S ) confirming that they dont have mod_wsgi but wsgiref...
So I'm a bit stuck here - which steps should I do next?
I'll update the question regularly based on comments and remarks. Any help is appreciated.

Since your apache is shared, I don't expect you can change the httpd.conf but use instead your solution. My suggestion is:
If you have multiple servers you will deploy your project (e.g. testing, staging, production), then do the following steps for each deploy target.
In each server, create a true wsgi.py file which you will never put in versioning systems. Pretty much like you would do with a local_settings.py file. This file will be named wsgy.py since most likely you cannot edit the apache settings (since it is shared) and that name will be expected for your wsgi file.
The content for the file will be:
#!/path/to/your/virtualenv/python
from my_true_wsgi import *
Which will be different for each deploy server, but the difference will be, most likely, in the shebang line to locate the proper python interpreter.
You will have a file named my_true_wsgi to have it matching the import in the former code. That file will be in the versioning systems, unlike the wsgi.py file. The contents of such file is the usual contents of the wsgi.py on any regular django project, just that you are not using that name directly.
With this solution you can have several different wsgi files with no conflict on shebangs.

You'll have to use a webhost that supports Django. See https://code.djangoproject.com/wiki/DjangoFriendlyWebHosts. Personally, I've used WebFaction and was quite happy with it, their support was great and customer service very responsive.

Deploying my Python app to Heroku breaks Heroku's Python interpreter

This is an old app, running since about two years on Heroku. Now suddenly, when I deploy (standard git push), it breaks the Python interpreter, both on regular and one-off dynos. Here's what it looks like:
$ heroku run python
Running `python` attached to terminal... up, run.8338
python: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory
Further pushes, heroku restart, scaling the dynos to zero and back up, that all doesn't fix it.
The only changes contained in this deployment which I could imagine being related to this problem are: gevent upgraded from 0.13.6 to 1.0.1 and the introduction of a runtime.txt (before there was none, resulting in 2.7.4, now there's one for 2.7.6).
I rolled all of this back to no effect, however. In fact, I went back about 30 commits (the deployment contained maybe five) and pushed that and the app is still broken.
Rolling back with heroku rollback is the only way I've found to take the app back into a usable state. But of course that doesn't help me going forward.
What might cause this? Can I somehow rebuild my whole app environment from scratch?
EDIT 1: I opened a shell in a one-off dyno and I can see the libpython2.7.so.1.0 file there:
/ $ ls -la /app/.heroku/python/lib/libpython2.7.so.1.0
-r-x------ 1 u49295 49295 5694572 2014-06-03 23:39 /app/.heroku/python/lib/libpython2.7.so.1.0
Of course I don't know if that's where it's supposed to be.

Somehow certain apps did not upgrade properly. A temporary fix to locate the correct python library:
heroku config:set LD_LIBRARY_PATH=/app/.heroku/python/lib

Kenneth Reitz from the Python team here.
So, we're rolling out security updates to the version of Python that we have installed on our base system. Customers shouldn't be affected by this in any way, because their apps use their own version of Python, and because we set local runtime-specific (such as LD_LIBRARY_PATH) in a .profile.d scripts, outside of user-set configuration.
However, we allow power users to override these environment variables with $ heroku config. That's basically what the application was doing — although, not knowingly. This was an accidental side-effect of a much, much older Heroku. In older days, we couldn't have any runtime-specific configuration without being a part of user configuration. This is why your application had an LD_LIBRARY_PATH config set, and this is what caused this bug.
Because of this, I've disabled the overridability of LD_LIBRARY_PATH for Python apps, and all should be well moving forward.
Thanks for being a part of the gradual rollout process, and thanks for helping us get to the bottom of this regression. I'm very sorry for the inconvenience.

Are you using the default Python buildpack? Heroku is in the process of updating the Stack image, and especially if you're not using a current buildpack, there may be incompatibilities.
To see if you're using a default buildpack, run
$ heroku config | grep BUILDPACK_URL
Please contact Heroku support if you think this might be the cause.

Windows with Plesk Panel installs ActiveState Python 2.5.0 - any thoughts?

I expect to run Pylons on a Windows Server 2003 and IIS 6 on a Virtual Private Server (VPS). Most work with the VPS is done through the Plesk 8.6 panel. The Plesk panel has a lot of maintenance advantages for us. However, this Plesk configuration installs ActiveState Python 2.5.0. The Parallels Plesk documents for 8.6 and version 9 insist that only this configuration should be installed.
I'm not eager to settle for the baseline 2.5.0. but don't see any safe upgrade path. How has ActiveState Python 2.5.0 been for other users? Can you replace the Parallels\Plesk\Additional\Python
with another distribution? I don't want to break Plesk, please.
Previously, I followed these instructions, Serving a Pylons app with IIS - Pylons Cookbook
Using the default web site IP address, I had Python 2.6.3 installing the ISAPI-WSGI dll in IIS so that I successfully ran Pylons in a virutalenv through IIS using the IP address, no domain name. I would be so happy if I could run this successful configuration for my domains while I must use Plesk.
Tips and solutions appreciated.

The default Python install location is something like c:\python26. I think it's likely you could install the latest python there, without it conflicting with the ActiveState Python. (You may have to deal with path issues or conflicts over which copy 'owns' python source files in Explorer, though.)

Practices while releasing the python/ruby/script based web applications on production

I am purely a windows programmer and spend all my time hacking VC++.
Recently I have been heading several web based applications and myself built applications with python (/pylons framework) and doing projects on rails. All the web projects are hosted on ubuntu linux.
The RELEASE procedures and check list we followed for building and releasing VC++ windows application are merely no more useful when it comes to script based language.
So we don't built any binaries now. I copied asp/php files into IIS folder through ftp server when using open source cms applications.
So FTP is the one of the way to host the files to the web server. Now we feel lazy or not so passionate to copy files via ftp instead we use the SVN checkout and we simply do svn update to get the latest copy.
Is SVN checkout and svn update are the right methods to update the latest build files into the server? Are there any downside in using svn update? Any better method to release the script/web based scripts into the production server?
PS: I have used ssh server at some extension on linux platform.

I would create a branch in SVN for every release of web application and when the release is ready there, I would check it out on the server and set to be run or move it into the place of the old version.

Is SVN checkout and svn update are the right methods to update the latest build files into the server?
Very, very good methods. You know what you got. You can go backwards at any time.
Are there any downside in using svn update? None.
Any better method to release the script/web based scripts into the production server?
What we do.
We do not run out of the SVN checkout directories. The SVN checkout directory is "raw" source sitting on the server.
We use Python's setup.py install to create the application in /opt/app/app-x.y directory tree. Each tagged SVN branch is also a branch in the final installation.
Ruby has gems and other installation tools that are probably similar to Python's.
Our web site's Apache and mod_wsgi configurations refer to a specific /opt/app/app-x.y version. We can then stage a version, do testing, do things like migrate data from production to the next release, and generally get ready.
Then we adjust our Apache and mod_wsgi configuration to use the next version.
Previous versions are all in place. And left in place. We'll delete them some day when they confuse us.

The one downside of doing an svn update on your web root is that the .svn directories can potentially be made public, so be careful about permissions on the web server.
That said, there are far better ways to deploy an app built with dynamic languages. In the Rails world Capistrano is a mature deployment tool, as well as Vlad the Deployer. Capistrano can easily be used for non-rails deployments
There are many deployment strategies based on version control. You could go through the tutorials and get some ideas.
I'd also like to add that even though we do not "build" (compile) the project in dynamic languages, we do "build" (test/integration) them. A serious project would use a continuous integration server to validate the integrated "build" of project on every commit or integration, well before it gets to production.

One downside of doing an svn update: though you can go back in time, to what revision do you go back to? You have to look it up. svn update pseudo-deployments work much cleaner if you use tags - in that case you'd be doing an svn switch to a different tag, not an svn update on the same branch or the trunk.
You want to tag your software with the version number something like 1.1.4 , and then have a simple script to zip it up application-1.1.4,zip, and deploy it - then you have automated repeatable releases and rollbacks as well as greater visibility into what is changing between releases.