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
python 2.7.10-0 fails to create virtualenv with Symbol not found: __PyErr_ReplaceException #1367
Comments
I can reproduce this. @ilanschnell we should probably see if we can fix this before the release. |
This is probably the same problem: |
I am experiencing a similar error with conda after installing mayavi 4.3 from a fresh Anaconda 2.2 installation on Mac OsX yosemite. It might be because of the upgrade from python 2.7.9 to 2.7.10.
And after when trying to use conda again:
|
Importing |
It works for me too, except when trying to create a virtualenv. I'm not sure what causes it, since the virtualenv seems to just put a symlink to the lib-dynload. |
If anyone is seeing this problem and is linked here from stack overflow, I worked around it by moving back to Python 2.7.9:
|
Which is the exact Python version you use? I still get the same error with:
|
I see the same problem on linux, and the |
As expected, there is some unholy business with my system and anaconda python executables:
|
@kyleabeauchamp - it sounds like you have a separate issue, so please log it separately. This one is specifically for "Symbol not found: __PyErr_ReplaceException" on Mac OS X when using Python 2.7.10-0 |
I think I was a bit unclear. I saw exactly the same error (__PyErr_ReplaceException) on linux with py2.7.10. The other error message I reported was only observed when I attempted the workaround (py2.7.9) described above. |
Any progress on this? |
I'm on OSX, and can confirm the |
A couple of months on, any news on when a fix will land @ilanschnell? |
I had python 2.7.10 on conda, and started experiencing this issue when I added Downgrading worked for me too. |
Downgrading fixed the problem for me as well. |
Downgrading also fixed this problem for me (I actually didn't notice this problem until it kept vim pymode from reporting any linter errors. go figure.) |
I ran the "conda install python=2.7.9", it says it installed ok. But when I do "python --version" I still see 2.7.10. What else I should do? |
This is probably a condo/virtualenv co-issue. Note that |
Known, unresolved, issue for 6+ months?!?! That's pretty disappointing. I ran into this after downgrading from 2.7.11 to 2.7.10, as recommended, due to another virtualenv / conda issue. Can't conda learn to play with others? Downgrading (again) from python 2.7.10 to 2.7.9 worked for me on OS X. The original 2.7.11 error was:
|
I just ran into this issue. In my case, the problem seems originate from having the DYLD_LIBRARY_PATH environment variable set; unsetting this environment variable fixes the issue. I didn't spend too much time debugging the issue, so I'm not 100% sure which dynamic library is actually the problem, but it seems like having DYLD_LIBRARY_PATH set causes the conda python interpreter to mistakenly load a dynamic library from outside its install directory. |
Setting these environment variables is never a good idea, unless you're trying to debug some wired linking problem. Any program will potentially change it's behavior (or break) when you set DYLD_LIBRARY_PATH, not just the Python we bundle in Anaconda. |
I don't know how else, for example, to dynamically link against the MATLAB-Python bridge: |
Downgrading fixed the problem for me as well. But I want to use Python 2.7.11 tu@mac ~/workspace $ mkvirtualenv dj17
New python executable in /Users/tu/.virtualenvs/dj17/bin/python
Installing setuptools, pip, wheel...done.
virtualenvwrapper.user_scripts creating /Users/tu/.virtualenvs/dj17/bin/predeactivate
virtualenvwrapper.user_scripts creating /Users/tu/.virtualenvs/dj17/bin/postdeactivate
virtualenvwrapper.user_scripts creating /Users/tu/.virtualenvs/dj17/bin/preactivate
virtualenvwrapper.user_scripts creating /Users/tu/.virtualenvs/dj17/bin/postactivate
virtualenvwrapper.user_scripts creating /Users/tu/.virtualenvs/dj17/bin/get_env_details
Error: deactivate must be sourced. Run 'source deactivate'
instead of 'deactivate'.
Usage: source deactivate
removes the 'bin' directory of the environment activated with 'source
activate' from PATH.
(dj17) tu@mac ~/workspace $ python
Python 2.7.10 (default, Oct 23 2015, 18:05:06)
[GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.0.59.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
(dj17) tu@mac ~/workspace $ deactivate
tu@mac ~/workspace $ python
Python 2.7.9 |Anaconda 2.5.0 (x86_64)| (default, Dec 15 2014, 10:37:34)
[GCC 4.2.1 (Apple Inc. build 5577)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
Anaconda is brought to you by Continuum Analytics.
Please check out: http://continuum.io/thanks and https://binstar.org
>>>
tu@mac ~/workspace $ which virtualenv
/Users/tu/anaconda2/bin/virtualenv
tu@mac ~/workspace $ which python
/Users/tu/anaconda2/bin/python
tu@mac ~/workspace $ python -V
Python 2.7.9 :: Anaconda 2.5.0 (x86_64)
tu@mac ~/workspace $ workon dj17
Error: deactivate must be sourced. Run 'source deactivate'
instead of 'deactivate'.
Usage: source deactivate
removes the 'bin' directory of the environment activated with 'source
activate' from PATH.
(dj17) tu@mac ~/workspace $ python -V
Python 2.7.10 |
downgrade python version to 2.7.9. Its working for me on OSX. |
Downgrading python to 2.7.9 not working on OSX yosemite PFB logs New python executable in analysis_python3/bin/python ...Installing setuptools, pip, wheel...done. |
February 2017, and still no solution not involving untested hacks. |
I confirm that the downgrade to Python 2.7.9 worked in my case. |
While it's buried above, here's a cross-link reference: conda-forge/staged-recipes#1139 There's not much conda can do to fix this. The problem is really structural with virtualenv. I'm not sure if anyone has yet filed an issue on the virtualenv tracker or not. |
@mingwandroid Has just released into repo.continuum.io a patched virtualenv package that fixes this issue. You must |
That's great news. Thanks s @mingwandroid and thanks Kale for letting me know. |
Great news indeed! 🎉🎉🎉 @mingwandroid |
No problem everyone. Personally, I much prefer conda envs to virtualenvs, but I wanted to fix this one because it seems to be important to your workflows. |
Tangential: @mingwandroid - how do you ensure repeatable builds of your conda environments? environment.yml or something else? |
Mostly I use a single root env. Conda-build creates the other envs that I frequently use (build and test ones) since I spend most of my time building conda packages rather than doing general computing, Python or data science work. |
But if I do need reproducibility, I use |
I am on OS Sierra(10.12) and downgrading fixed the issue for me. downgrade code via @pjbull : conda install python=2.7.9 |
@brlrb - can you try doing a |
I'm on OS Sierra and downgrading also fixed this issue for me. |
@marchofreason, this core problem here is fixed so I do not understand why you needed to downgrade. You should instead install the latest conda If it does not I would appreciate exact reproduction steps. Here are mine: Python 3:
final line outputs:
Python 2:
final line outputs:
|
wow... yeah, macOS 10.12, downgrade also fixed it for me. |
@jbmaxwell - @mingwandroid fixed this problem, no need to downgrade. Please see comments above... There's a reason this issue is closed! |
Works for me too |
Hi there, thank you for your contribution to Conda! This issue has been automatically locked since it has not had recent activity after it was closed. Please open a new issue if needed. |
This morning I wanted to create a virtualenv on Mac OS X where my default python is now anaconda, so I needed to install virtualenv:
However, now when I try to create the env I get this error:
Downgrading to Python 2.7.9-1 made this problem go away.
It looks like I'm not the only one experiencing this:
http://stackoverflow.com/questions/30674338/upgrade-to-python-2-7-10-target-wsgi-script-cannot-be-loaded-as-python-module
The text was updated successfully, but these errors were encountered: