Since Django 1.9a1 was released, many users are going to upgrade their project and wonder why django-autocomplete-light won’t load anymore. Probably, some users are going to google ImportError or even django.core.exceptions.AppRegistryNotReady: Apps aren't loaded yet about autocomplete_light and Django 1.9. This post documents the situation and provides a solution.

Do:

    find test/ -name foo -exec sed -i 's/import autocomplete_light/from autocomplete_light import shortcuts as autocomplete_light/' '{}' \;

I don’t remember why exactly since we’ve baked Django 1.9 support in April 2015 (victory !!!), but IIRC due to app-loading refactor we can’t have anything in __init__.py for installed apps just for convenience anymore (ie. model imports). To maintain as much backward compatibility as possible, we still load what we can there, but please use autocomplete_light.shortcuts instead.

Getting started with SaltStack usually means piling up a bunch of YAML code templated with Jinja in a source code repository because that’s the way to go from the documentation’s point of view. With significant whitespace, YAML enables even non-developers to define data structures in non verbose way. Jinja2 is a templating engine which enables a non-developer to make YAML files dynamic, typically depending on variables. However, Jinja2 hasn’t significant whitespace and this can decrease readability of YAML templates. And since YAML and Jinja2 are two different languages in the same file, there is no readable way to ident code. Not to mention that Jinja2, as a template language rather than a programing language, has a pretty limited subset of operators.

After 8 release candidates, we’ve got our new shining 2.2.0 release of django-autocomplete-light which literally drown the backlog, we’re down to less than one github page of issues now. Needless to say, we’ve closed an insane amount of issues with 2.2.0.

Please read the release notes before upgrading.

This article presents the changelog for django-autocomplete-light 2.2.0 release. To upgrade to 2.2.0rc1:

pip install -U --pre django-autocomplete-light

If you find any problem, please report it on github issues and downgrade to last stable (2.1.x series):

pip install -U django-autocomplete-light

Pending break warning, Django >= 1.9

The good old import autocomplete_light API support will be dropped with Django 1.9. All imports have moved to autocomplete_light.shortcuts and importing autocomplete_light will work until the project is used with Django 1.9.

SaltStack is an Open Source DevOp tool to automate administration of a computer (server or desktop) infrastructure, typically but not limited to, developing in-house PaaS. Travis-ci is an Open Source Continuous Integration platform and online-hosted for free for Open Source projects.

This article targets SaltStack formula developers who wants to have CI enabled

• and of course every SaltStack user should be a formula developer wanting CI.

Overview

First things first, we have to test the /pillar.example file located at the top of the formula repository. Unfortunately, it’s not straightforward, I’ve started a discussion on salt-users in case we find a way to improve that.

The last article demonstrated how we could simply make any https flow going out a virtual bridge network interface through mitmproxy to cache anything.

In this article, we’ll focus on the logic to “cache anything” from within our mitmproxy script.

Design

We’d like each fetched file to be stored in a directory as is to make it easy to tweak the cached content:

• remove a file from the cache directory to force the proxy to re-fetch it,
• fill the cache directory with your own files,
• have the cache directory mountable in a memory (ie. a tmpfs directory).

So, for example:

This article describes how to get a working transparent HTTP/HTTPS proxy which you can script in Python. I intend to use it to have custom caching and be able to abstract away all HTTP/HTTPS connections made in my LXC containers which are spawned by CI to be able to test deployment scripts even when internet is down. A nice journey ;)

First, install mitmproxy with pip:

pip install mitmproxy

mitmproxy documentation describes the iptables commands to intercept Assuming you have LXC with Nat. Basically, we want iptables to route all outgoing requests to port 80 (http) and 443 (https) to mitmproxy, it looks like:

Today is the grand openning of our Arch Linux package repository, with the release of postgresql-bdr. It’s a patched PostgreSQL server with BiDirectionnal Replication which seems too good to be true. I ran split brain tests and it reacted amazingly well, although it needs all nodes to be up for schema updates which is ok to me because I won’t be running upgrades while I have a broken node: I’ll be working on fixing it.

Pluggable models have come to django-cities-light thanks to Alexey Evseev. It’s completely backward compatible and allows you swap default models with your own as well as connecting to new signals the geonames import command.

On the behalf of YourLabs, I’d like to welcome Alexey Evseev aboard ! I recommend hiring with Alexey Evseev if you have the chance and trust in with your mission.

Upgrade instructions:

pip install -U django-cities-light

Don’t forget to read how to customize your models with django-cities-light it’s ultra simple.

Travis-ci just released container based infrastructure for open source repository (free users).

We tried it with our apps, and you can see we had some performance increase, even on database-intensive jobs:

• django-autocomplete-light normal build takes around 1 hour and 35 minutes while it takes rather 1 hour and 22 minutes with container based build](https://travis-ci.org/yourlabs/django-autocomplete-light/builds/45086517) so that’s around a 10% build speed increase, pretty cool right ? read on ;)
• django-cities-light normal build takes around 5 hours and 45 minutes, on travis-container it takes around 3 hours and 30 minutes !
• No notable performance increase to note on django-session-security.