Having closely read your posts above, I think the problem you were having was because you were using the command python3
in your bash consoles when you were running the manage.py
scripts, instead of using python3.5
.
In newly-created PythonAnywhere accounts, python3
starts Python 3.5 (which is probably why my colleagues didn't pick up on this). But in order to avoid breaking backward-compatibility, for older accounts it maps to the most recent version of Python 3 at the time the account was created. For your account, this means it points to Python 3.4.
This explains the weird behaviour you saw. Our current system install of Django for Python 3.4 is 1.6, and for Python 2.7 it's 1.3.7. So the errors you saw Django version mismatch errors, because you'd selected Python 3.5 but were running with one or the older versions.
A couple of follow-on points:
-
When you are using Django management commands, you don't actually need to specify the Python interpreter. If you're in the directory that contains manage.py
, then you can just do things like this:
This means that you don't need to remember anything about the Python version -- it just works.
* You mention south, which doesn't exist in Django 1.9 -- database migrations were integrated into Django in Django 1.7.
Just for completeness -- I created a Django 1.9 app using Python 3.5 in a fresh account, and here are the steps I followed:
That all worked fine. Because those steps bypass the need to name the specific Python version on the Bash command line by running manage.py
directly, they'd work in your account too.