Clean head install of invoke causes ImportError

[davidfischer]

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

I can see six.py in vendor/ but it looks like this is a simple import error since six isn't installed system wide and there's no six.py 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

[treyhunner]

@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.

[bitprophet]

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!

[bitprophet]

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 !

[justinmayer]

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/pkg_resources.py", line 378, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
File "/virtualenvs/testenv/lib/python3.3/site-packages/pkg_resources.py", line 2566, in load_entry_point
    return ep.load()
File "/virtualenvs/testenv/lib/python3.3/site-packages/pkg_resources.py", line 2260, in load
    entry = __import__(self.module_name, globals(),globals(), ['__name__'])
File "/virtualenvs/testenv/lib/python3.3/site-packages/invoke/__init__.py", line 2, in <module>
    from .tasks import task, ctask, Task
File "/virtualenvs/testenv/lib/python3.3/site-packages/invoke/tasks.py", line 11, in <module>
    from .context import Context
File "/virtualenvs/testenv/lib/python3.3/site-packages/invoke/context.py", line 3, in <module>
    from .runner import run
File "/virtualenvs/testenv/lib/python3.3/site-packages/invoke/runner.py", line 6, in <module>
    from .vendor import pexpect
File "/virtualenvs/testenv/lib/python3.3/site-packages/invoke/vendor/pexpect.py", 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]

@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.

[bitprophet]

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.

[bitprophet]

Fixed & released as part of 0.5 :)

[justinmayer]

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