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

No module named 'six' #1042

Closed
davidism opened this Issue Jun 1, 2017 · 27 comments

Comments

Projects
None yet
@davidism

davidism commented Jun 1, 2017

Flask's Tox/Travis builds all started failing. Looks like a new version of setuptools was just released that has a problem with six.

Obtaining file:///home/david/Projects/flask
Installing collected packages: Flask
  Running setup.py develop for Flask
    Complete output from command /home/david/Projects/flask/.tox/py/bin/python3 -c "import setuptools, tokenize;__file__='/home/david/Projects/flask/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" develop --no-deps:
    /home/david/Projects/flask/.tox/py/lib/python3.6/site-packages/setuptools/dist.py:336: UserWarning: Normalizing '0.13-dev' to '0.13.dev0'
      normalized_version,
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/home/david/Projects/flask/setup.py", line 109, in <module>
        '''
      File "/usr/lib64/python3.6/distutils/core.py", line 134, in setup
        ok = dist.parse_command_line()
      File "/home/david/Projects/flask/.tox/py/lib/python3.6/site-packages/setuptools/dist.py", line 363, in parse_command_line
        result = _Distribution.parse_command_line(self)
      File "/usr/lib64/python3.6/distutils/dist.py", line 472, in parse_command_line
        args = self._parse_command_opts(parser, args)
      File "/home/david/Projects/flask/.tox/py/lib/python3.6/site-packages/setuptools/dist.py", line 674, in _parse_command_opts
        nargs = _Distribution._parse_command_opts(self, parser, args)
      File "/usr/lib64/python3.6/distutils/dist.py", line 528, in _parse_command_opts
        cmd_class = self.get_command_class(command)
      File "/home/david/Projects/flask/.tox/py/lib/python3.6/site-packages/setuptools/dist.py", line 495, in get_command_class
        self.cmdclass[command] = cmdclass = ep.load()
      File "/home/david/Projects/flask/.tox/py/lib/python3.6/site-packages/pkg_resources/__init__.py", line 2303, in load
        return self.resolve()
      File "/home/david/Projects/flask/.tox/py/lib/python3.6/site-packages/pkg_resources/__init__.py", line 2309, in resolve
        module = __import__(self.module_name, fromlist=['__name__'], level=0)
      File "/home/david/Projects/flask/.tox/py/lib/python3.6/site-packages/setuptools/command/develop.py", line 11, in <module>
        from setuptools.command.easy_install import easy_install
      File "/home/david/Projects/flask/.tox/py/lib/python3.6/site-packages/setuptools/command/easy_install.py", line 49, in <module>
        from setuptools.py27compat import rmtree_safe
      File "/home/david/Projects/flask/.tox/py/lib/python3.6/site-packages/setuptools/py27compat.py", line 7, in <module>
        import six
    ModuleNotFoundError: No module named 'six'

Example failed build log: https://travis-ci.org/pallets/flask/jobs/238166427#L242

@thanatos

This comment has been minimized.

thanatos commented Jun 1, 2017

I am seeing a very similar traceback; these seem to correspond w/ the release of setuptools==36; I'm trying to repro locally to see if rolling that back fixes.

@davidism

This comment has been minimized.

davidism commented Jun 1, 2017

This doesn't happen if I manually create a virtualenv. In that case, setuptools==36.0.0 is installed but installing packages works fine.

@dstufft

This comment has been minimized.

Member

dstufft commented Jun 1, 2017

It looks like an import got missed for being rewritten to import from the vendored packages.

elliterate added a commit to elliterate/capybara.py that referenced this issue Jun 1, 2017

Temporarily avoid broken version of setuptools
The relase of setuptools 36.0.0 introduced a broken import.

See: pypa/setuptools#1042

elliterate added a commit to elliterate/capybara.py that referenced this issue Jun 1, 2017

Temporarily avoid broken version of setuptools
The relase of setuptools 36.0.0 introduced a broken import.

See: pypa/setuptools#1042
@dmsimard

This comment has been minimized.

dmsimard commented Jun 1, 2017

Thanks for identifying the issue quickly.

This is currently plaguing most of our python-based jobs, would appreciate a release ASAP once the pull request #1043 lands.

elliterate added a commit to elliterate/capybara.py that referenced this issue Jun 1, 2017

Temporarily avoid broken version of setuptools
The release of setuptools 36.0.0 introduced a broken import.

See: pypa/setuptools#1042
@elliterate

This comment has been minimized.

elliterate commented Jun 1, 2017

I was able to temporarily work around this, first, by upgrading my CI environment to just short of v36 with the following pre-install command:

pip install --upgrade "setuptools < 36"

Then, by ensuring that my soon-to-be-created virtualenv inherited that version with the following environment variable:

VIRTUALENV_NO_DOWNLOAD=1
@cumber

This comment has been minimized.

cumber commented Jun 1, 2017

I was able to work around this by manually running pip install six in my new virtualenv, before installing anything else. It was able to reuse a cached wheel for six though; not certain that it would have worked otherwise.

@badone

This comment has been minimized.

badone commented Jun 1, 2017

A quick fix would be nice. This is affecting our builds as well.

@silvana-i

This comment has been minimized.

silvana-i commented Jun 1, 2017

Adding one more report for this issue. We are using virtualenv, which installs the faulty setuptools version. Afterwards when installing our project dependencies with pip install -r requirements.txt it is choking on the download of a custom package from a locally hosted pypi server. It fails during package collection, so the only thing that we found to fix it is to call pip install six before installing the requirements.txt.

@asottile

This comment has been minimized.

asottile commented Jun 1, 2017

For what it's worth, I made a tox plugin to avoid virtualenv's download behaviour for exactly this reason

Simply pip install tox-virtualenv-no-download alongside tox

@escapewindow

This comment has been minimized.

escapewindow commented Jun 1, 2017

virtualenv --no-download PATH will probably work for virtualenv>=14.0.0; that'll prevent hitting pypi for the new setuptools when creating the virtualenv.
https://virtualenv.pypa.io/en/stable/changes/

Ah, VIRTUALENV_NO_DOWNLOAD is even better, as it doesn't break on virtualenv<14.0.0

@fengxx

This comment has been minimized.

fengxx commented Jun 1, 2017

can we have a emergency release for the bugfix?

badone added a commit to badone/ceph that referenced this issue Jun 1, 2017

ceph-disk, ceph-detect-init: Add missing "six" module
Fixes problem noted at pypa/setuptools#1042

Signed-off-by: Brad Hubbard <bhubbard@redhat.com>

@rouge8 rouge8 referenced this issue Jun 1, 2017

Merged

Fix unbound __str__ on Python 2 when slots=True #199

4 of 6 tasks complete
@fake-name

This comment has been minimized.

fake-name commented Jun 1, 2017

It appears you can work around the issue by manually installing six before the dependencies that require it.

tchaikov added a commit to tchaikov/ceph that referenced this issue Jun 1, 2017

install-deps.sh: workaround setuptools' dependency on six
see also pypa/setuptools#1042

Signed-off-by: Kefu Chai <kchai@redhat.com>

fake-name added a commit to fake-name/AutoTriever that referenced this issue Jun 1, 2017

@fengxx

This comment has been minimized.

fengxx commented Jun 1, 2017

there is a workaround like VIRTUALENV_NO_DOWNLOAD=1 but the issue will cause trouble for virtualenv user who doesn't know the workaround.

be-hase added a commit to line/line-bot-sdk-python that referenced this issue Jun 1, 2017

fake-name added a commit to fake-name/AutoTriever that referenced this issue Jun 1, 2017

Add workaround for pypa/setuptools#1042
# Conflicts:
#	util/WebRequest/tests/test_phantom.py

tchaikov added a commit to tchaikov/ceph that referenced this issue Jun 1, 2017

install-deps.sh: workaround setuptools' dependency on six
see also pypa/setuptools#1042

Signed-off-by: Kefu Chai <kchai@redhat.com>

graingert added a commit to graingert/setuptools that referenced this issue Jun 1, 2017

@graingert

This comment has been minimized.

graingert commented Jun 1, 2017

Smallest passing build #1047

antocuni added a commit to antocuni/capnpy that referenced this issue Jun 1, 2017

@ilovezfs

This comment has been minimized.

ilovezfs commented Jun 1, 2017

Fix confirmed here as well: Homebrew/homebrew-core#14130.

@pabelanger

This comment has been minimized.

pabelanger commented Jun 1, 2017

@dstufft If possible, please do not delete packages that have already been tagged and released to pypi. This puts local mirrors in an awkward position of now having an unreleased packaging mirrored.
I know you are not the maintainer but it would have been better to tag 37.0.0 reverting 36.0.0 to 35.x.x

@graingert

This comment has been minimized.

graingert commented Jun 1, 2017

I know you are not the maintainer but it would have been better to tag 37.0.0 reverting 36.0.0 to 35.x.x

that will probably happen soon. Deleting 36 was the fastest way to get travis working again.

@pabelanger

This comment has been minimized.

pabelanger commented Jun 1, 2017

While it was the fastest way to get TravisCI working again, it breaks other CI systems in the process. It is never possible to delete something from the internet, there will always be a cache somewhere.

@Natim

This comment has been minimized.

Natim commented Jun 1, 2017

@jaraco I downloaded the files to my computer, if you want to restore 36.0 let me know and I can do it.

It won't be possible to upload them again actually...

@andreibacos

This comment has been minimized.

andreibacos commented Jun 1, 2017

As someone in the process of removing 36 from our internal devpi caches, @pabelanger made a good point.

@Natim

This comment has been minimized.

Natim commented Jun 1, 2017

I don't really know the normal release process of setuptools, so I wouldn't feel comfortable cutting a release

The release process is documented here

I don't think relying on a single person to fix a so central Python package is a good thing. It puts a lot of pressure on their shoulder while we could handle it on our side.

I wouldn't consider it to be a bleeding, its part of the life of a project to ship broken releases once in a while.

The release process of a python project is to release a new version to fix a release.

I would be glad to cut a release myself if you give me necessary permissions.

@matthew-brett

This comment has been minimized.

matthew-brett commented Jun 1, 2017

@Natim - see #1045 for a request to add release candidate builds to the release process.

@Natim

This comment has been minimized.

Natim commented Jun 1, 2017

Yes that's probably a good idea too. Thanks @matthew-brett

@jaraco jaraco closed this in 1cebea7 Jun 1, 2017

jaraco added a commit that referenced this issue Jun 1, 2017

Merge pull request #1043 from alex/patch-1
fixed #1042 -- updates an import to use six from the vendored package
@jaraco

This comment has been minimized.

Member

jaraco commented Jun 1, 2017

Please see this comment regarding my apology and intention for the project maintenance.

vaidap pushed a commit to vaidap/zulip that referenced this issue Jun 2, 2017

setup_venv: Pin a version of setuptools for creating venvs.
This works around a bad recent setuptools release:

pypa/setuptools#1042

ahawker added a commit to ahawker/scratchdir that referenced this issue Jun 4, 2017

benoit-pierre added a commit to benoit-pierre/setuptools that referenced this issue Jul 14, 2017

Renari pushed a commit to Renari/line-bot-sdk-python that referenced this issue Nov 6, 2017

Support 'user_id' in SourceGroup and SourceRoom (line#48)
* Support 'user_id' in SourceGroup and SourceRoom

* Add new line.

* Add docstring comments

* workaround (pypa/setuptools#1042)

reorx added a commit to reorx/rdl that referenced this issue Apr 28, 2018

give up py27 tox testing in travis
something is wrong with tox-py27 & travis: pypa/setuptools#1042
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment