• #555 Django 1.4, 1.5 and 1.6 deprecation
• #497 Enable registration by model-name by @luzfcb
• #536 #551 Support proxy models b y @onrik
• #553 improved jQuery integration by @blueyed
• #516 Corrected french transation by @apinsard
• #541 Use error_messages on FieldBase to allow overrides by @dsanders11
• #505 Ordering alias clash fix by @sandroden
• #515 Polish translation update by @mpasternak
• #543 ModelChoiceField requires the queryset argument
• #494 ModelChoiceField Watch changes to ‘queryset’ by @jonashaag
• #514 Fixed deprecation warning on Django 1.8 by @spookylukey
• #498 #548 improved i18n support
• #547 prevents loading genericm2m if not in INSTALLED_APPS
• JAL#18 Fix: Get value.length while value is null by @hongquan
• JAL#19 Clarify license by @stevellis, all MIT
• JAL#17 Disable the widget input when it is not in use @dsanders11
• JAL#15 Support openning results in new tab @thebao
• JAL#14 Don’t autohilight first choice by default @pandabuilder
• JAL#13 Add option for box aligning with right edge of input @dsanders11

#536 At this point, proxy model support is untested, this is because I intend to refactor the test suite and documentation during the 2.3.x serie.

I’m pretty lazy when it comes to writing tests for existing code, however, I’m even lazier when it comes to repetitive manual testing action, we’ve got so much patches to review and test against so many versions of Python and Django, we need testing to be automated.

This article presents a new Django app for testing the database. Java has DBunit and so does PHP, and django now has django-dbdiff.

Database testing

A nice way to test a data import script is to create a source data fixture with a subset of data, ie. with only 10 cities instead of 28K or only 3 european parliament representatives instead of 3600, feed the import function with that and then compare the database state with a django fixture. This looks like what I was used to do:

django-cities-light 3.2.0 was released, supporting Django 1.7 to 1.9 now, even though older versions should still work, they aren’t tested anymore.

• #105: Drop LazyProgressBar, patch was accepted upstream by Max Arnold,
• #104: Better feature code filtering by Max Arnold and Michael Gulev,
• #100, #96: The mystery about migrations appearing in some environments but not others has been solved: it was due to the presence of b'' in migration files. A new test was added to fail if django wants to create new migrations in any environment.
• Phone number was required to create a country, it’s not anymore.
• Support Django 1.7 to 1.9, thanks Georgy Kutsurua for helping,
• Support for 1.7 will drop when 1.10 is released, unless someone contributes compatibility in cities_light options declaration,
• Bugfix in import: some search names would not be generated in some cases due to unpredictability of the iteration order on translation_data.items()
• Test with django-dbdiff are much faster than importing the whole data
• Tox for testing, coverage

Starting 2.3.0, django-session-security supports Django 1.7 to Django 1.10 with tox.

In 2.3.1, Andrei Coman added redirectTo parameter and tests were stabilized using django-sbo-selenium and tox.

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: