New minor release

We’ve just upgraded PythonAnywhere with a bunch of stability fixes. One nice new thing: if you create a new web2py app, you’ll get version 2.0.9 – and even better, the build-in “upgrade” button in the web2py admin view now works – just click it, click OK, then once it’s done, use the “Reload web app” button on the Web tab of your PythonAnywhere dashboard.

Unlimited private git repos for Python Developers

At PythonAnywhere we love github as much as the next person. It’s great! We use it for our main private repository and have a few public ones up there as well.

But sometimes you just want a private place to backup your little project to. And if you are like me you have about 30 little projects that are the software equivalent of napkin scribbling. Or maybe you think github is a little bit too cool. Maybe it’s trying too hard?

Git fresh!

incidentally Git Fresh are PythonAnywhere’s favourite Miami based R&B-Hip-Hop like product

So sure you could just make those repos public but urgh. Not everything is public. Sometimes they are private to just you or sometimes you want to work on something with just a couple of other collaborators.

Read more…

New release!

This is mostly a performance and stability release, but we do have 2 of our most requested forum features:

  • Permalinks to particular forum posts are now shown next to the post
  • The forums are now searchable

Enjoy and send us any comments and feedback.

Developing PythonAnywhere on PythonAnywhere - Dogfooding part deux.

We’ve been “dogfooding” PythonAnywhere for about 6 months now - it always seemed right that, if we were building an online development environment, we should probably actually use it to build itself. Pleasingly recursive, to say nothing of helping to focus our dev process.

Until now though, we were using a special, dedicated cluster that replicates the live environment, but that allowed us to do certain things like use NFS to edit code on our dev VMs. But last week we made the switch to actually using the live, production servers.

So we’re now using exactly the same environment as our users - and it’s been quite an eye-opener. It’s made us bump certain things right up our priority queue.

Read more…

New release - several stability and security fixes

Not a lot of very visible changes, but we’ve been beavering away at some security and stability tweaks.

  • Thanks to a2j for pointing out a potential security hole which potentially allowed people to view some scheduled task logs that weren’t their own. We’re very pleased to have that fixed.
  • We’ve implemented better isolation and load balancing, to make sure that individual users or groups of users can’t hog resources. We’ve also tipped the scales so that paying users get more CPU than free users, if there’s ever any contention between the two on a given server…
  • We’ve moved some of our own “housekeeping” cron jobs onto their own server, so they don’t steal cycles from our beloved users
  • We’ve added several useful packages - splinter (thanks douglasmccormickjr), gitpython (thanks nicozanf), and openpyxl (thanks anonymous tipster) and python-magic (no idea who suggested that!)

We’ve also installed sshfs - more on that later, when we talk about Phase 2 of our “developing PythonAnywhere on PythonAnywhere” dogfooding adventure. Watch this space!

New deploy! Python2.7 is now the default, plus some perf. improvements

Hi All!

A long-requested, and much overdue feature today - Python2.7 is now the default, meaning it’s the default python at the command line, it’s the default python when you use pip or easy_install, but most importantly, it’s the default Python for your web apps!

NB - this means any custom packages you’ve installed for your web app using the --user flag need to be reinstalled. If you didn’t get the memo, you may need to do that now!

Aside from that, we’ve had several little tweaks and performance improvements:

  • improvements to console responsiveness
  • squid proxy should be more resilient
  • reduced swappiness on the web servers to reduce thrashing (thanks Cartroo)
  • randomised default start time on scheduled tasks (thanks a2j!)
  • implemented the uwsgi idle timeout for workers (thanks Roberto!)
  • Fixed the subversion proxy bug (thanks ccoovrey)

Thanks to everyone that’s reported bugs suggested improvements, or nagged us for new features. In particular: profread, mjmare, MorePyPlease, decisioncandy and egasimus.

Happy Python-two-dot-seven-ing!

New release! Hashbangs in Save & Run, infrastructure tweaks, new packages

Finally, finally, finally we’ve implemented a way for people to run scripts with different flavours of Python from the “Save & Run” button.

It’s still a first-cut, but you can now use hashbangs to specify which python version will be used when you hit the “Save & Run” button in the editor.

So this:

#!/usr/bin/python3.2
print "hello"

Will produce an error. woo.

Aside from that, we’ve added a few new python packages:

And a couple of little helper executables to your tools in Bash, including tree and lsyncd (more on that later).

Thanks to aramik, Cartroo, cwbh10, transium, johkershaw and jhafranco for their suggestions which got into this release.

nginx+uWSGI vs Apache - why we switched.

nginx logo uWSGI logo Apache logo

Beloved users, and whomever else may find it of interest,

We recently made the switch from Apache to nginx with uwsgi. Well, I say recently, as far as I can tell from the commit logs we started work on it around July 10th, so that’s almost two months ago! We just deployed it last week, and after a bumpy first few days it seems to be settling in well. We thought we’d share why we switched, and how it’s going.

tl;dr:

We switched because:

  • we need to dynamically configure new virtualhosts for our users
  • Apache won’t dynamically load config, it needs a restart graceful which is still too disruptive
  • a single, generic Apache config that handles all users is getting unweildy
  • nginx+uwsgi will make it much easier for us to do things like static files and per-user config tweaks
  • we’re also hoping for some performance improvements

Our experience was:

  • sure enough, nginx+uwsgi is much simpler to configure and much more flexible. but:-
  • Apache’s model is to only start workers when they’re needed. uwsgi starts them all up-front. That took some hacking, since we actually wanted the on-demand behaviour.
  • no perf. improvements out-of-the-box, but we think there’s lots of potential for tuning
  • we did plenty of functionality testing, but not enough load testing, so our first deploy was a little rough.

Onto the detail!

Read more…

Learn how to code a Facebook app in 20 minutes on PythonAnywhere

[Warning! this tutorial was written in August 2012, and so is probably out of date]

This tutorial aims to teach you how to create and publish a simple Facebook app in about 20 minutes using PythonAnywhere.

Read more…

New release

We had a bit of downtime this afternoon while we deployed a new version of PythonAnywhere. Bad timing really because we’ve been getting some love over at the Python subReddit

  • We’ve added task helpers for new users. These are walk throughs of common tasks. If you sign up now you’ll be prompted to start one. If you are an existing user and want to use one then visit your Account page to get started.

  • The Webapps page has had a redesign in preparation for multiple web apps and giving users more control over things like where their static files are served from.

  • There is also a new PythonAnywhere media resources page.

Enjoy!