Skip to content
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
Closed

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

sloria opened this issue Jun 9, 2014 · 3 comments

Comments

@sloria
Copy link

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants