Two years on, and I still love the combination of tox and Travis. I still write changes to my tox.ini and .travis.yml files separately, despite having written a tool for this. It occurred to me yesterday that there was a better way of writing this now - since tox now has a command for listing out what environments are set up (something which I think didn't exist when I wrote the original Python script).
I love tox - it's a great tool for checking that your Python packages are installable, and that you support all the various configurations of Python versions and other package versions that you think you do.
Yesterday, I found two bugs whilst looking at a code coverage report. I tend to think that shooting for 100% code coverage adds unnecessary overheard - often the last few percent doesn't give you much benefit, and takes a disproportionate amount of time to reach, but it's useful to at least understand why particular lines of code aren't hit by your tests. Perhaps those lines are dead code, or perhaps - as was the case for me yesterday - it's because your code is broken.
A new version of Django was released a couple of days ago. I'm currently at 11 sites using Django, so upgrading them all manually (which I did last time) is a pain. To help me out, I wrote a tiny Fabric script to spin through my sites, check if they're using the version of Django that was upgraded, and if they are, upgrade them.
I do a lot of development without an internet connection[1. Mostly on the train to and from work.], so being able to install packages into a virtual environment without a connection to PyPI is pretty useful.
I tried out Fabric a while ago, but never really got anywhere with it. Time passed, and I forgot it existed, and wrote my simple scripts for automating deployment of my various sites, using Paramiko. It was incredibly tedious, but meant I could deploy my sites from whatever computer I was on, provided I had a checkout of my code. Then I re-discovered Fabric, and realised I was about to throw away a lot of code.
Upcoming releases of Django will remove django.contrib.markup, but I still want to use it. I looked around for alternatives (perhaps a third party app?), before deciding to roll my own.
Order(n) is a pretty bad idea. Originally, my SearchIndexes for Haystack looked a bit like this: Then, when someone ran a search, and I wanted to display a result, I'd load up a template (which template I loaded depended on grabbing the model name, as recommended in the docs), and any attributes of the model I wanted to display required doing a database lookup to fetch the data, like this: This has a fairly obvious problem - each time you display a search result, you do a database [Read more...]
A long while ago, I discovered that running Django tests is much faster if you use SQLite, and if you turn off South (this now seems pretty obvious, but at the time was a bit of a revelation to me).
I'd basically given up on attempting test-driven with Django, given the project I'm currently working on uses models with a lot of South migrations. Just building the database and running the migrations could take a minute or so when running manage.py test, and resetting the database to a clean state meant the test suite would take several minutes to run.