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
Comments
I am seeing a very similar traceback; these seem to correspond w/ the release of |
This doesn't happen if I manually create a virtualenv. In that case, setuptools==36.0.0 is installed but installing packages works fine. |
It looks like an import got missed for being rewritten to import from the vendored packages. |
The relase of setuptools 36.0.0 introduced a broken import. See: pypa/setuptools#1042
The relase of setuptools 36.0.0 introduced a broken import. See: pypa/setuptools#1042
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. |
The release of setuptools 36.0.0 introduced a broken import. See: pypa/setuptools#1042
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:
Then, by ensuring that my soon-to-be-created virtualenv inherited that version with the following environment variable:
|
I was able to work around this by manually running |
A quick fix would be nice. This is affecting our builds as well. |
Fixes problem noted at pypa/setuptools#1042 Signed-off-by: Brad Hubbard <bhubbard@redhat.com>
Adding one more report for this issue. We are using virtualenv, which installs the faulty setuptools version. Afterwards when installing our project dependencies with |
For what it's worth, I made a Simply |
Ah, |
can we have a emergency release for the bugfix? |
Fixes problem noted at pypa/setuptools#1042 Signed-off-by: Brad Hubbard <bhubbard@redhat.com>
It appears you can work around the issue by manually installing six before the dependencies that require it. |
see also pypa/setuptools#1042 Signed-off-by: Kefu Chai <kchai@redhat.com>
there is a workaround like VIRTUALENV_NO_DOWNLOAD=1 but the issue will cause trouble for virtualenv user who doesn't know the workaround. |
# Conflicts: # util/WebRequest/tests/test_phantom.py
see also pypa/setuptools#1042 Signed-off-by: Kefu Chai <kchai@redhat.com>
Smallest passing build #1047 |
Fix confirmed here as well: Homebrew/homebrew-core#14130. |
@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. |
that will probably happen soon. Deleting 36 was the fastest way to get travis working again. |
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. |
It won't be possible to upload them again actually... |
As someone in the process of removing 36 from our internal devpi caches, @pabelanger made a good point. |
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. |
Yes that's probably a good idea too. Thanks @matthew-brett |
fixed #1042 -- updates an import to use six from the vendored package
Please see this comment regarding my apology and intention for the project maintenance. |
This works around a bad recent setuptools release: pypa/setuptools#1042
* Support 'user_id' in SourceGroup and SourceRoom * Add new line. * Add docstring comments * workaround (pypa/setuptools#1042)
something is wrong with tox-py27 & travis: pypa/setuptools#1042
Flask's Tox/Travis builds all started failing. Looks like a new version of setuptools was just released that has a problem with six.
Example failed build log: https://travis-ci.org/pallets/flask/jobs/238166427#L242
The text was updated successfully, but these errors were encountered: