Clean head install of invoke causes ImportError #55

davidfischer opened this Issue Mar 16, 2013 · 8 comments


None yet

4 participants

% virtualenv venv
% source venv/bin/activate
% git clone git://
% cd invoke
% python install
% inv
Traceback (most recent call last):
  File "build/bdist.macosx-10.8-intel/egg/invoke/vendor/lexicon/", line 1, in <module>
ImportError: No module named six

I can see in vendor/ but it looks like this is a simple import error since six isn't installed system wide and there's no in vendor/lexicon.

This is actually my first interaction with invoke so maybe I'm doing it wrong.

Here's some platform info:

% python --version
Python 2.7.2
% uname -a
Darwin nibbler 12.2.1 Darwin Kernel Version 12.2.1: Thu Oct 18 12:13:47 PDT 2012; root:xnu-2050.20.9~1/RELEASE_X86_64 x86_64
@davidfischer davidfischer referenced this issue in pyca/pynacl Mar 16, 2013

Public key #15


@davidfischer it looks like six is a dependency. Also invocations is a dependency and it must be installed from the git repository because it's not on PyPI yet.


Yea, this is my bad, the vendored copy of lexicon inside Invoke is trying to globally import six, which won't exist unless you install it manually (which is a legit workaround for now). I'll figure out a fix and update things soon. Thanks!


Just pushed a fix. I'm not proud of it, but I can now run Invoke in a virtualenv that has no global 'six' installed. Please reopen if this somehow didn't fix it for you, @davidfischer !

@bitprophet bitprophet closed this Mar 17, 2013

Just ran into a similar problem with Invoke 0.4.0 on Mac OS X 10.8.4, Homebrew Python 3.3.2:

> virtualenv -p /usr/local/bin/python3 testenv
> (testenv) pip install invoke
> (testenv) pip list --local
invoke (0.4.0)
pip (1.4.1)
setuptools (0.9.8)

Don't see six in the above list, and I don't have it installed globally. Let's try an invocation:

> (testenv) invoke --install python-deps
Traceback (most recent call last):
File "/virtualenvs/testenv/bin/invoke", line 9, in <module>
    load_entry_point('invoke==0.4.0', 'console_scripts', 'invoke')()
File "/virtualenvs/testenv/lib/python3.3/site-packages/", line 378, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
File "/virtualenvs/testenv/lib/python3.3/site-packages/", line 2566, in load_entry_point
    return ep.load()
File "/virtualenvs/testenv/lib/python3.3/site-packages/", line 2260, in load
    entry = __import__(self.module_name, globals(),globals(), ['__name__'])
File "/virtualenvs/testenv/lib/python3.3/site-packages/invoke/", line 2, in <module>
    from .tasks import task, ctask, Task
File "/virtualenvs/testenv/lib/python3.3/site-packages/invoke/", line 11, in <module>
    from .context import Context
File "/virtualenvs/testenv/lib/python3.3/site-packages/invoke/", line 3, in <module>
    from .runner import run
File "/virtualenvs/testenv/lib/python3.3/site-packages/invoke/", line 6, in <module>
    from .vendor import pexpect
File "/virtualenvs/testenv/lib/python3.3/site-packages/invoke/vendor/", line 93, in <module>
    from .. import six
ImportError: cannot import name six

Any thoughts? Let me know if you'd prefer this in a new issue.

@bitprophet bitprophet reopened this Aug 16, 2013

@justinmayer I can recreate this under Python 3 (but not Python 2) - interestingly it's not caught by our test suite/CI because the test runner itself has a non-vendored dependency on 'six' (whereas in normal, non dev/test situations, Invoke relies on its vendored copy of 'six' - thus the from .. import six.)

Not sure why a relative import is picking up a 'global' install, I guess that fallback is on purpose.

And of course, not sure why the core problem exists: Python 3 breaks the relative importing. Could swear I had some folks using this under Python 3 previously. Will poke a bit.


Yea that's my bad, it needs to be from . import six - the .. was leftover from when pexpect was vendorized one level deeper.

Python 2 appears to pick up the relative 'six' in a non-relative import (i.e. import six was finding the vendorized six under Python 2 - but not Python 3).

Simplifying and fixing that entire import block; it seems to work for me without any global six installed, under both interpreters.

Thanks & sorry @justinmayer! Will release this change today.


Fixed & released as part of 0.5 :)

@bitprophet bitprophet closed this Aug 16, 2013

No apologies necessary, Jeff. On the contrary — thanks for jumping on this so quickly and pushing a release containing the fix. You rock!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment