conflicts with six.moves

[Christopher L. Trudeau]

I've been using django to interface with a couple of data source libraries, both of which use six. There appears to be some sort of conflict problem between six and django.utils.six which causes ImportErrors.

For example, using the Reddit library "praw":

> from six.moves.urllib.parse import parse_qs, urlparse, urlunparse

ImportError: No module named urllib.parse

or from Google-API:

>>> from apiclient.discovery import build

from six.moves import urllib

ImportError: cannot import name urllib

When looking around the web for problems with six, the common answer is to change the order of the import so that the more recent copy is first, obviously I can't do that if things are wrapped inside of django.  I have tried six v1.4, 1.8 and 1.9, none of which work.

I have tried explicitly removing django.utils.six's _SixMetaPathImporter from sys.meta_path before doing the imports and it still fails.  In debugging I have found that anything in six that is a MovedModule will fail to import but those things that are MovedAttribute objects still work.

I have django installed in a virtualenv.  I have tried this with Django 1.7.5 and 1.8.2 with no luck.  If I run the import commands from the python interpreter directly they work, but if I run the same import command from "./manage.py shell" the import fails.

In playing around I instrumented the non-django copy of six and was able to get it to list all of its module values including those it can't import.  So on one hand the module thinks it is there, but the import hook fails.

I'm not even 100% sure this is a django problem and not a conflict with some other library in the virtualenv, I do know that something that "manage.py" brings into the path is causing issues.  Any help would be greatly appreciated.  My head is sore from banging against this particular wall.
...ct

[ctru...@arsensa.com]

After much banging of my head against the brick wall I finally figured this out.  It was not django causing the problem.  Replying here in case anyone else experiences something similar.  There were about a dozen different libraries that use six.py all of which have their own copy instead of expressing a dependency.  One of these (IMAPClient v0.11) had an extremely out of date version of six (v1.1) which was only being loaded in the django environment but not in the python one.  Thankfully, updating the IMAPClient library to v0.12 also brought their six up to v1.7 which solved the problem.

I'm not sure why everyone seems to include their own copy of six.py, especially seeing as the most recent versions even have code that tries to make sure only one of them is loaded at a time.  We have all these dependency mechanisms and yet everyone just copies and pastes the code. 
...ct