pymssql and Docker

I’ve done quite a bit of work on pymssql, which is a Python interface for Microsoft SQL Server. Now pymssql is a Python wrapper on top of a C library called FreeTDS and historically, a lot of folks have had various problems with downloading and building an appropriate FreeTDS (this seems to be especially true on older Linux distros and on Windows where there is no package manager and FreeTDS is somewhat harder to build (e.g.: see my instructions on building FreeTDS on Windows, which are fairly complicated). There is now a new way to easily get started with pymssql: Docker

I merged https://github.com/pymssql/pymssql/pull/258 which adds a Dockerfile and instructions on how to use the Docker pymssql image that I uploaded to the Docker registry at:

https://registry.hub.docker.com/u/pymssql/pymssql/

In a nutshell, if you have Docker, you should be able to do:

docker pull pymssql/pymssql
docker run -it --rm pymssql/pymssql

and this should launch an IPython shell that has pymssql available as well as some other data goodies like pandas, SQLAlchemy, and Alembic.

Full details at http://pymssql.org/en/latest/intro.html#docker

My hope is that this allows a greater number of people to use pymssql and to use it with less hassle because they don’t have to worry about stuff like building FreeTDS and what not. With Docker, things should just work, so I think this could be useful for a lot of people.

Comments are welcome and probably the best way to suggest additions or changes to the Docker image is to file a GitHub issue at https://github.com/pymssql/pymssql/issues

Also posted to pymssql Google Group at https://groups.google.com/forum/?fromgroups#!topic/pymssql/ltqyjF5UBjw

Seeing info when changing virtualenvs with virtualenvwrapper

I wanted to see a bit about virtualenvs when I activate them with workon from virtualenvwrapper.

I added the following to $VIRTUALENVWRAPPER_HOOK_DIR/postactivate:

#!/bin/bash
# This hook is run after every virtualenv is activated.

python -V
easy_install --version
pip --version

Here’s how it looks:

$ workon pip
Python 2.7.6
setuptools 3.6
pip 6.0.dev1 from /Users/marca/dev/git-repos/pip (python 2.7)

For more information on customizing with hooks, read the docs.

New MacBook Pro Retina

Our new MacBook Pro Retina arrived while we were in Hawaii.

Our old MacBook Pro was getting long in the tooth. It was a pre-unibody, 2007 model, 2.4 GHz Intel Core 2 Duo with 4 GB of RAM, a 500 GB spinning disk drive, and OS X 10.6.8 (Snow Leopard).

The new one has a Retina display, 2.8 GHz processor, 16 GB RAM and a 1 TB SSD and it’s running OS X 10.9.4 (Mavericks).

It’s been challenging to migrate files from the old laptop to the new one, as the old one keeps crashing.

Pull request to allow supervisor to send arbitrary signals to processes

https://github.com/Supervisor/supervisor/pull/477

Let’s you do stuff like:

$ supervisorctl
cat:0                            RUNNING   pid 57305, uptime 0:00:07
cat:1                            RUNNING   pid 57304, uptime 0:00:07
cat:2                            RUNNING   pid 57307, uptime 0:00:07
cat:3                            RUNNING   pid 57306, uptime 0:00:07
cat:4                            RUNNING   pid 57308, uptime 0:00:07
dog:0                            RUNNING   pid 57300, uptime 0:00:07
dog:1                            RUNNING   pid 57299, uptime 0:00:07
dog:2                            RUNNING   pid 57302, uptime 0:00:07
dog:3                            RUNNING   pid 57301, uptime 0:00:07
dog:4                            RUNNING   pid 57303, uptime 0:00:07
supervisor> help signal
signal <signal name> <name>	      Signal a process
signal <signal name> <gname>:*        Signal all processes in a group
signal <signal name> <name> <name>    Signal multiple processes or groups
supervisor> signal 1 dog:3 dog:4
dog:3: signalled
dog:4: signalled
supervisor> signal HUP dog:3 dog:4
dog:3: signalled
dog:4: signalled
supervisor> signal HUP dog:*
dog:1: signalled
dog:0: signalled
dog:3: signalled
dog:2: signalled
dog:4: signalled
supervisor> signal USR1 dog:1 dog:2
dog:1: signalled
dog:2: signalled

Also, if you can’t wait for supervisor to support this, the mr.laforge package supplies a supervisor plugin that can be used to send signals to processes:

$ supervisorctl kill HUP nginx

That said, it would be nice to have this built into supervisor…