Unit testing GAE apps within a virtualenv

I recently ran into an issue when trying to run my usual nosetests against a newly created GAE-based app:

ImportError: No module named google.appengine.api

The SDK installs outside of Python shared modules and obviously has no idea about any virtualenv that you've set up in your project directory. The way I have my project set up is:

+ root
  + src
    +- app.yaml
    + [linked pip installed packages]
    + [module]
      +- tests.py 
  + env
  +- [virtualenv]

Adding GAE package directories to a gae.pth file in [virtualenv]/lib/site-packages did the trick for me and I was able to run unit tests without jumping through nose plugin or custom test runner hoops:

gae.pth:

/path/to/google_appengine
/path/to/google_appengine/lib/yaml/lib
/path/to/google_appengine/lib/fancy_urllib

Of course, this list will grow as you add tests that depend on more SDK modules.

Following Google's local unit testing documentation (service stubs, etc.) got everything else set up just fine for me.

Admittedly, I'm running on Windows 7 and not my OS of choice. However, the solution should translate just fine to a Linux/Mac machine as well.

OAuth 2.0 (client) couldn't get any easier

Sanction

I'm pleased to introduce sanction, a Python OAuth 2.0 client in all of its 66 LOC of glory:

https://github.com/demianbrecht/sanction

Why another OAuth 2.0 client?

I found that most implementations were overly complex, sometimes adhering to architecture principles taught in school, sometimes not. All, however, simply felt much more convoluted and difficult to understand than I thought they should be. My initial attempt at writing my own client resulted in a ~450 LOC implementation that I was quite pleased with at the time. However, after a heated discussion with Jack Diederich, watching his talk "Stop Writing Classes", spending some time waist deep in Python in a professional capacity, subsequently buying into the slogan "We're all consenting adults here" and finally realizing that I didn't want to maintain the code unless there were bugs (I wanted to release a fire-and-forget library), I decided I wasn't so happy with it anymore.

So, after spending some time (again waist deep) with the OAuth 2.0 spec, I forged ahead with a rewrite and subsequently, surprised myself when it ended up being a whopping 66 LOC. This library shouldn't need to be updated when new providers are implemented. As long as the providers adhere to the OAuth 2.0 spec, it'll work out of the box. If there are deviations (such as Facebook and StackExchange), client code will need to be aware of it and handle it as shown in the example code (nothing special, 4 LOC to handle Facebook and StackExchange deviations).

Provider Support

As of this writing, sanction has been tested with the following providers:

• Facebook (include the test API)
• Google
• Foursquare
• bitly
• GitHub
• StackExchange
• Instagram
• DeviantArt

Examples for each are included on github. Usage is detailed in the README.

The sanction library is also available and can be downloaded from PyPi.

Installing MongoDB as a service on Windows 7

Note to self:

When installing MongoDB as a service on Windows 7, don't rely on the PATH variable to access the executable. When installing the service via mongod --install, the service path is inferred, so when you attempt to net start, it won't find the executable (an absolute path is required).

In other words,

mongod --install

should be

C:\path\to\mongod --install

There goes 45 minutes of my day. Thank god it's Friday.