We try to get a newsletter out every month, but in August we were all too busy working on our latest and greatest features to manage it. It wasn't that we were all out sunning ourselves, honest :-)
Here's what we were up to:
This is actually quite a big deal, even if it might seem a bit dull at first glance. Accounts that have been created since 8 September have more recent versions of all of our batteries included. For example, while older accounts have Django 1.3.7 installed for Python 2.7, newer accounts get Django 1.10. The old image is called "classic" because we couldn't think of a better name, and the new one is called "dangermouse" because we remember the children's television of the UK in the 1980s much too well.
So, why did this take so long? And why do we think it's a big deal? Well, one of the development practices we follow here is what we call "Embarrassment-Oriented Project Management". In a nutshell, this says "if you're trying to work out what you need to work on next, ask yourself what makes you blush when you have to explain it to someone"... One of the things that was a tad embarassing was that we only supported Django 1.3.7 for Python 2.7. Sure, we supported later Django versions for later Python versions, but still.
But we had a problem. Until now, everyone on our site had to use the same system image, with the same versions of everything. We could add new things -- which is why, when Python 3.5 was installed, it had recent versions of all the system packages. But we couldn't upgrade anything for older Python versions, because it would have meant breaking any code that people had running that depended on the old system models. If you had a Django 1.3.7 website, and we upgraded to 1.10, then your site would suddenly stop working, and you'd have to change the code to make it work again. That would have been rather rude of us, so we didn't do it.
So what we needed to do was develop a way for different people to have different system images. For a while, we thought that Docker was the solution -- but unfortunately (for reasons related to scalability in our specific environment) it turned out not to be. So we've extended our virtualization system to support multiple system images.
More images will come in the future, once we've thought of an appropriately-irreverent name starting with "E" for the next one.
Right, enough of that! What else?
Let's Encrypt is a project supported by the Linux Foundation to help secure the web by providing free HTTPS certificates for any domain you own. Its certificates are just as good as ones that you pay for in almost every way -- the only downside is that you have to renew them once every few months rather than once a year. (That's also a security feature, of course, because if someone steals your private key then they can only impersonate you for a few months rather than a year. But it is a little inconvenient.)
On PythonAnywhere, you already get free HTTPS for your websites that are subdomains of pythonanywhere.com -- you don't need to do anything -- but if you have a custom domain, you need to give us a certificate to install. We've been honing our process to make this as easy as possible, and we're now pretty confident in them. So now there's no excuse to not secure your website -- just follow the instructions here.
app.config['SQLALCHEMY_POOL_RECYCLE'] = 280, and (less obviously) don't forget that you have to do that before you do
db = SQLAlchemy(app)!
Although you can install Python packages on PythonAnywhere yourself, we like to make sure that we have plenty of batteries included.
Because of the new system image, we've not actually added any new modules this time around -- but we've updated everything we could to the latest version for the new "dangermouse" image. You can compare and contrast the different version in each image over on the new, shiny, interactive batteries included page.
Paying PythonAnywhere customers get unrestricted Internet access, but if you're a free PythonAnywhere user, you may have hit problems when writing code that tries to access sites elsewhere on the Internet. We have to restrict you to sites on a whitelist to stop hackers from creating dummy accounts to hide their identities when breaking into other people's websites.
But we really do encourage you to suggest new sites that should be on the whitelist. Our rule is, if it's got an official public API, which means that the site's owners are encouraging automated access to their server, then we'll whitelist it. Just drop us a line with a link to the API docs.
Here are some sites we've added since our last newsletter:
Thanks for reading our newsletter! Tune in the same time next month (ish) for more news from PythonAnywhere.