New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error on 0.8.0: ImportError: No module named vendor #140

Closed
sloria opened this Issue Jun 9, 2014 · 3 comments

Comments

Projects
None yet
2 participants
@sloria

sloria commented Jun 9, 2014

When I try to run any task, I get the following error:

Traceback (most recent call last):
  File "/Users/sloria/miniconda/envs/osf/bin/inv", line 9, in <module>
    load_entry_point('invoke==0.8.0', 'console_scripts', 'inv')()
  File "/Users/sloria/miniconda/envs/osf/lib/python2.7/site-packages/pkg_resources.py", line 356, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "/Users/sloria/miniconda/envs/osf/lib/python2.7/site-packages/pkg_resources.py", line 2439, in load_entry_point
    return ep.load()
  File "/Users/sloria/miniconda/envs/osf/lib/python2.7/site-packages/pkg_resources.py", line 2155, in load
    ['__name__'])
  File "/Users/sloria/miniconda/envs/osf/lib/python2.7/site-packages/invoke/__init__.py", line 2, in <module>
    from .tasks import task, ctask, Task
  File "/Users/sloria/miniconda/envs/osf/lib/python2.7/site-packages/invoke/tasks.py", line 8, in <module>
    from .vendor import six
ImportError: No module named vendor

invoke version: 0.8.0
Python version: 2.7.7
OS: Mac OSX 10.8

@bitprophet

This comment has been minimized.

Member

bitprophet commented Jun 9, 2014

Thanks, yup, we broke the setup.py. (Really need to get Travis testing non-editable installation sometime...)

bitprophet added a commit that referenced this issue Jun 9, 2014

@bitprophet

This comment has been minimized.

Member

bitprophet commented Jun 9, 2014

Found a straightforward enough way to test this locally & in Travis, verified, reverted to using find_packages (meh). I feel like there may have been some reason to avoid find_packages but can't recall what it is now - if somebody complains later we'll suck it up and manually list all subpackages.

Presuming Travis gives the thumbs up I'll release the fix as 0.8.1.

@bitprophet

This comment has been minimized.

Member

bitprophet commented Jun 9, 2014

Yup that seems to pass/fail correctly. Just pushed 0.8.1 to PyPI. Thanks again!

@bitprophet bitprophet closed this Jun 9, 2014

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