Pull request for Python pip installer accepted

https://github.com/pypa/pip/pull/374

The pull request addresses a UnicodeDecodeError bug in pip. It affects pip in Python 3 and it’s triggered when a package install fails and emits Unicode characters to the console. A classic case of this are gcc error messages which use exotic quotes.

It adds a test for the issue and then fixes it. Fixing this also required making a fix to Ian Bicking’s ScriptTest package, which was incorporated in ScriptTest 1.2.

The pip fix has not been included in an official pip release yet.

phpserialize on Python 3

I was playing around with phpserialize and found out that phpserialize doesn’t work on Python 3.

However, I put together a GitHub fork that works with Python 3 (and also has tests, especially for Unicode which is the real gotcha when porting from Python 2.x to Python 3.x):

To use this, I put

-e git+git://github.com/msabramo/phpserialize.git@python3.x#egg=phpserialize

in my pip requirements file.

For Tox (a recent find and a very nice tool), this needs to be tweaked because it uses ConfigParser to parse its ini file and ConfigParser swallows the stuff after the # as a comment (I could find no way to escape the #; others have noticed this too). So in my tox.ini I used:


https://github.com/msabramo/phpserialize/tarball/python3.x

for the deps setting.

Full tox.ini for the curious:

More pull requests accepted into South

I had a few more of my contributions accepted into South:

Bitbucket pull request #10: Make `schemamigration` output more readable and PEP8-compliant
Bitbucket pull request #11: Print the failing SQL when a query fails
Bitbucket pull request #12: For manage.py migrate –list –verbosity=2, print the datetime that migrations were applied
Bitbucket pull request #13: Add ability to migrate forwards and backwards easily one by one

print_settings: A super simple and useful custom Django management command

A large number of problems that we have with our Django project at work turn out to be because of settings that are not what they should be (note that our settings are not straightforward to see with a glance at settings.py since we use multiple settings files for production, dev, and common settings). I thought that it might be useful to have a Django management command that shows the settings in effect after all the settings files are processed.

It was super easy to write and is a tiny amount of code, but I have a feeling that this will quickly curtail a lot of problems.

Sample invocation: