Skip to content

"sphinx-build not found" error in a Py3k venv #1263

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

Closed
NYKevin opened this issue May 8, 2015 · 14 comments · Fixed by #1316
Closed

"sphinx-build not found" error in a Py3k venv #1263

NYKevin opened this issue May 8, 2015 · 14 comments · Fixed by #1316

Comments

@NYKevin
Copy link

NYKevin commented May 8, 2015

Possible duplicate of #994, but I'm not sure because I'm seeing weird Py3k errors. Also, the latest branch is building successfully, but another branch is failing.

See e.g. https://readthedocs.org/builds/nbtparse/2722836/

Under build standard error:

/bin/sh: 1: /home/docs/checkouts/readthedocs.org/user_builds/nbtparse/envs/version-0.5.0/bin/sphinx-build: not found

Under environment standard error:

Traceback (most recent call last):
  File "/home/docs/local/lib/python2.7/site-packages/virtualenv.py", line 8, in <module>
    import base64
  File "/usr/lib/python3.4/base64.py", line 9, in <module>
    import re
  File "/usr/lib/python3.4/re.py", line 324, in <module>
    import copyreg
  File "/home/docs/lib/python2.7/site-packages/copyreg/__init__.py", line 7, in <module>
    raise ImportError('This package should not be accessible on Python 3. '
ImportError: This package should not be accessible on Python 3. Either you are trying to run from the python-future src folder or your installation of python-future is corrupted.

If the branch+project name is too long, I'm stumped. Making my tags any shorter would make the repository potentially confusing for human users, since I use a mixture of tags, branches, and bookmarks. Worse, tag and branch names are (mostly) permanent in the Mercurial data model. Any advice?

@paternal
Copy link

paternal commented May 9, 2015

Same problem here. Compilation of most of my projects stopped working without any change to the repository. And here either, neither project name nor branche name seems to be too long. Examples of failed compilation : pdfautonup dummypdf.

@estin
Copy link

estin commented May 11, 2015

seems like some problems in virtualenv version or PATH environ variable (some hooks?)

venv
-----

Traceback (most recent call last):
  File "/home/docs/local/lib/python2.7/site-packages/virtualenv.py", line 8, in <module>
    import base64
  File "/usr/lib/python3.4/base64.py", line 9, in <module>
    import re
  File "/usr/lib/python3.4/re.py", line 324, in <module>
    import copyreg
  File "/home/docs/lib/python2.7/site-packages/copyreg/__init__.py", line 7, in <module>
    raise ImportError('This package should not be accessible on Python 3. '
ImportError: This package should not be accessible on Python 3. Either you are trying to run from the p

virtualenv running under python2.7, but have some imports from python3.4 in this traceback

Sorry for my poor English

@ericholscher
Copy link
Member

This appears to be a bug with Python or Virtualenv. When we run virtualenv-2.7 -p python3 venv it breaks with that error.

@ericholscher
Copy link
Member

I talked with @dstufft about work arounds, but there doesn't appear to be much we can do currently.

@dstufft
Copy link

dstufft commented May 12, 2015

One option is to install virtualenv into Python 3 and run python3 -m virtualenv instead of virtualenv -p python3

@NYKevin
Copy link
Author

NYKevin commented May 12, 2015

When we run virtualenv-2.7 -p python3 venv it breaks with that error.

In my experience, trying to use the 2.7 version of Virtualenv to create a 3.x venv doesn't tend to work very well, at least on Ubuntu.

@makmanalp
Copy link

I'll also put in a +1, I'd be happy to test out any workarounds.

@zmwangx
Copy link

zmwangx commented May 12, 2015

My experience with creating a py3k virtualenv with virtualenv 2.7 is the opposite; never had a problem, if I recall correctly. I'm on OS X though.

> virtualenv-2.7 --version
1.11.6

@makmanalp
Copy link

The odd thing is while I was fiddling with settings I had gotten it to work at some point:

So I'm confused as to how that ever happened. Here's a recent failure: https://readthedocs.org/builds/atlas-core/2742978/

@zmwangx
Copy link

zmwangx commented May 12, 2015

@ericholscher By the way, since you already have py3k installed anyway, why can't you just invoke virtualenv-3.4 to create a py3k virtualenv?

@makmanalp
Copy link

OK, so funny discovery, I thought I figured out that it works when a github push triggers the build, but not manually! Check it out, auto-build after github push:

https://readthedocs.org/builds/atlas-core/2743001/

But then I triggered it manually again and it works again! See this:

https://readthedocs.org/builds/atlas-core/2743009/

@NYKevin
Copy link
Author

NYKevin commented May 13, 2015

Hm... bug seems to be transient. A manual trigger worked for me, too.

@cjw296
Copy link

cjw296 commented May 18, 2015

Same thing for me: github push fails, manual trigger works. Any eta on a fix?

takluyver added a commit to takluyver/readthedocs.org that referenced this issue Jun 1, 2015
Fixes readthedocsgh-1263, failure to create Python 3 virtualenvs (I hope)

The problem appears to be that `virtualenv -p python3` re-executes its
own file in site-packages as a script under Python 3. Because the
directory containing a script is prepended to `sys.path`, the contents
of Python 2 site-packages are then on sys.path for Python 3. [python-
future](http://python-future.org/) is installed in Python 2, providing
certain standard library modules under their Python 3 names. So when it
tries to import copyreg, it finds the compatibility module for Python 2
instead of the standard Python 3 module, making future fail with the
error:

ImportError: This package should not be accessible on Python 3. Either
you are trying to run from the python-future src folder or your
installation of python-future is corrupted.

As suggested by @dstufft, this invokes `python3 -m virtualenv` instead,
which will cause Python 3 to run its own copy of virtualenv, and should
avoid this issue. This requires virtualenv to be installed in Python 3
as well; I don't know if it already is, but it should be easy to arrange
if not.
@takluyver
Copy link
Contributor

So long as virtualenv is installed on Python 3, #1316 should fix it (using @dstufft's suggestion - thanks!)

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

Successfully merging a pull request may close this issue.

9 participants