This let me figure out that my modwsgi wasn’t using the Python that I thought it was.
sudo lsof -c httpd | grep python
This let me figure out that my modwsgi wasn’t using the Python that I thought it was.
sudo lsof -c httpd | grep python
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.
My pull request (to fix a Unicode bug that I discovered while working on a bug in pip) was accepted for inclusion in Ian Bicking‘s ScriptTest package.
I had some code accepted into Twisted to solve a bug related to Unicode. The bug is actually 2 years old and I first got involved 23 months ago (in December of 2009), so it’s good to see the loop finally closed.
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:
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
Bitbucket pull request #13: Add ability to migrate forwards and backwards easily one by one
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: