Hi, how do I set the python version to run wsgi.py? Specifically I'm trying to set up the combination python2.7/django1.4/mezzanine1.1.4

Hi Alexei,

You are going to want to run this in a virtualenv. Glenn gives some good instructions on how to do so here. Give it a go and see how far you get and if you run into any problems just ask here.

Ok, I'll give that a go.

How efficient is this approach likely to be? Will two python interpreters have to be fired up for each page request (whatever apache launches to process wsgi.py and the interpreter in the virtual env) or does the stack maintain running instances?

For that matter I noticed you are running 64bit linux same as my machine .. if I chuck the entire virtual env and django application (including database - it's using sqlite3) onto Dropbox I could set everything up on my dev machine and just hit run on PA ... Is this approach silly? It sure would make development and backup trivial but I can imagine something could go a bit crazy with dropbox backing up changes, and I'm cringing at the result of the two machines accessing the db, though it might be ok depending on how the locking is done.

Hi Alexei,

The wsgi.py virtualenv approach should be fine - we only load wsgi.py once, and subsequent requests don't need to re-run the execfile.

Re: virtualenv + Dropbox, my colleague Glenn tells me that doesn't work, because virtualenv relies on full paths. There is a tool called "relocate" that's supposed to help, but rumours say it doesn't work too well...

Re: dropbox, actually what really kills this approach is that Dropbox doesn't respect symlinks and permissions. Never mind syncing via ssh is fine.

.. and it doesn't appear possible to be able to change python versions on the fly. From what I can see the wsgi is stuck with python2.6 ... not been able to find any reliable confirmation of this though.

It isn't currently possible to change the Python version from 2.6. We're working on making Python 2.7 the default, but it's dependent on some big changes that we're working through now. Expect it soonish

For what its worth, would like to have 2.7 as default as well

We're actually working on it this week! We'll need to send everyone an email to tell them to get prepared for the switch... watch this space...

Hey guys, any progress on that? My Django app still seems to be run by Python 2.6...

@egasimus: Welcome to Python Anywhere. I hope your experience here is as awesome as mine has been!

@all: An infinite number of mathematicians walk into a bar. The first one orders a beer. The second orders half a beer. The third, a quarter of a beer. The bartender says "You're all idiots", and pours two beers.

@a2j - very good :-)

As I say, we need to prepare the move to Python2.7 quite carefully. One reason is, people who have used pip-2.6 install to install custom packages will not have them installed for python 2.7. So, if we were to switch immediately, we would break any number of users' webapps.

So we have to announce the migration well in advance, and give everyone time to prepare for it. So we need to do a little more testing at our end, we need to think through the migration plan, and you will definitely hear from us by email, well ahead of the move.

This raises a question about possibly giving us the ability to see into the test builds. Does your integration environment perform any testing for users? Okay before I start rambling I better define where I'm going here. I guess it's really a feature request, so here goes.

Feature Request

Some method for us to have tests run as part of the PA integration process so we get notified when an upcoming build will break whatever we are testing for so we can fix it prior to the roll out. Rather than me speculate about how it would be best to accomplish this idea...is it something PA has thought about or already made plans for? If not, will you?

We test for everything that we can think of that effects the stability of the platform. I don't think we want to get into a state of stasis. We want to be able to provide the latest stable versions of Python packages while allowing users to pin their applications to certain versions of packages. This is where virtualenvs come into their own. Before we deploy a new version of PythonAnywhere that has any potential of actually breaking anything we would either announce it or design a transparent (no work required on your behalf) fix for anyone that might be affected.

I love your confidence, but for the same reason you have all your integration testing, I don't know how it can work if the client apps aren't being integration tested. Things will slip through the cracks. However, you think you can do it, so I will accept that answer.