I successfully use mypyc in my project and it has performed well until just a couple days ago. I now get the following error:
File "mypyc/__main__.py", line 18, in <module>
KeyError: '__file__'
Line 18 above, i.e., the line that is failing, is just
base_path = os.path.join(os.path.dirname(__file__), '..')
which I wouldn't expect to fail. I am in my venv virtualenv when I execute mypyc using the same command as has always worked before.
I thought perhaps a regression was introduced in mypyc so I used git to go back in time to see if that line had changed in any recent version of mypy, but it hadn't.
I also tried downgrading mypy to an older version that worked before but that version also failed with the same error. To be sure it wasn't being experienced by others I also checked the issues at the mypy repo on github and did a search for __file__ to see if that part of the error message showed up and it didn't. Perhaps it is some weird issue with my environment?
I experience the issue with venv virtualenvs created with Python 3.10, 3.10.1 but also 3.9.9 too. It worked fine on Python 3.10 before. Any ideas on what to investigate next?
Related
Details
I am getting a build failure of my read-the-docs that I don't understand. The assertion of "verbatim" in line 2151 of nbsphinx.py is causing the build failure. So the build fails when I try to include the Jupyter Notebook tutorials I created. I compared current versions of the tutorials to previous versions which had not caused the build to fail, and I can't find a difference that could account for the current failure.
Read the Docs project URL: lofti_gaia
Build URL: https://github.com/logan-pearce/lofti_gaia
Read the Docs username: logan-pearce
Expected Result
A passing build including *.ipynb files
Actual Result
Build failed at line 2151 of nbsphinx.py due to assertion of 'Verbatim' failing.
Terminal output:
Running Sphinx v4.1.2
loading translations [en]... done
making output directory... done
WARNING: html_static_path entry '_static' does not exist
loading pickled environment... done
building [mo]: targets for 0 po files that are out of date
building [latex]: all documents
updating environment: 0 added, 0 changed, 0 removed
looking for now-outdated files... none found
processing lofti_gaia.tex... index installation tutorials/QuickStart tutorials/Tutorial api lofti loftitools
resolving references...
done
writing... failed
Exception occurred:
File "/home/docs/checkouts/readthedocs.org/user_builds/lofti-gaia/conda/latest/lib/python3.7/site-packages/nbsphinx.py", line 2151, in depart_codearea_latex
assert 'Verbatim' in lines[0]
AssertionError
The full traceback has been saved in /tmp/sphinx-err-x1h83s3m.log, if you want to report the issue to the developers.
Please also report this if it was a user error, so that a better error message can be provided next time.
A bug report can be filed in the tracker at <https://github.com/sphinx-doc/sphinx/issues>. Thanks!
According to the github issue 584 for nbsphinx (https://github.com/spatialaudio/nbsphinx/issues/584), this is due to a compatibility issue with sphinx 4.1.0. It can be gotten around by requiring sphinx version 4.0.2.
So in my requirements.txt file, I included sphinx==4.0.2, after which the build passes. So now my requirements.txt file looks like:
numpy
matplotlib
astropy>=4.0.1.post1
astroquery>=0.4
sphinx==4.0.2
ipython==7.19.0
nbsphinx>=0.8.6
and the build passes.
I have encountered the same issue. I did not solve it with .ipynb format, but converting the jupyter notebook to .rst format works.
May it helps
I am running a virtual environment with Python 2.7 for my program.
There seems to be a problem after creating the executable file on windows.
I ran venv/Scripts/pyinstaller.exe -F main.py
everything seems fine. But when i click on the created executable main.exe.
There is an error.
Tried and tested
I have re-installed of pandas and pyinstaller
Implemented the hook-pandas.py to the hooks folder in the environment.
hook-pandas
Ensured the environment is activated.
Checked that the program is running fine before building executable.
Re-created the environment.
Yet after all that, I am prompted with this issue [see Importerror] when I run the executable file.
It is an extreme pain to debug this because the command prompt displaying the error will not pause but close almost immediately.
Similar issues
Looking for Suggestions
I am hoping for suggestions to troubleshoot Pyinstaller. Any resources to read up on would be nice.
Usually, I have no trouble with python as Pycharm has several handy debugging tools that will help me identify the problem
I ran into the same problem and found this thread, but I managed to solve it borrowing from the reference you posted (about pandas._libs.tslibs.timedeltas), so thank you for that!
In that article, the module that resulted in the ImportError was, in fact pandas._libs.tslibs.timedeltas, if you look at the poster's logs. But the error you and I ran into refers to np_datetime instead. So, from the traceback logs, I finally figured out that the code we have to write in hook-pandas.py should be the following:
hiddenimports = ['pandas._libs.tslibs.np_datetime']
Maybe that alone will solve your problem, HOWEVER, in my case, once I solved the np_datetime issue, other very similar ImportError problems arose (also related to hiddenimports regarding pandas), so, in case you run into the same issues, just define hiddenimports as follows:
hiddenimports = ['pandas._libs.tslibs.np_datetime','pandas._libs.tslibs.nattype','pandas._libs.skiplist']
TL;DR:
You can first try to write
hiddenimports = ['pandas._libs.tslibs.np_datetime']
into hook-pandas.py. However, if for some reason you run into the exact same issues I did afterwards, try
hiddenimports = ['pandas._libs.tslibs.np_datetime','pandas._libs.tslibs.nattype','pandas._libs.skiplist']
If you wish to dive deeper (or run into a different pandas ImportError than the ones I did), this is the code in pandas's __init__.py referenced in your traceback log (lines 23 to 35):
from pandas.compat.numpy import *
try:
from pandas._libs import (hashtable as _hashtable,
lib as _lib,
tslib as _tslib)
except ImportError as e: # pragma: no cover
# hack but overkill to use re
module = str(e).replace('cannot import name ', '')
raise ImportError("C extension: {0} not built. If you want to import "
"pandas from the source directory, you may need to run "
"'python setup.py build_ext --inplace --force' to build "
"the C extensions first.".format(module))
From that I went into the
C:\Python27\Lib\site-packages\pandas_libs
and
C:\Python27\Lib\site-packages\pandas_libs\tslibs
folders and found the exact names of the modules that resulted the errors.
I hope that solves your problem as it did mine.
Cheers!
Today's (1 Mar 2016) OpenSSL release has caused the following error when running Plone/Zope
.buildout/eggs/ZODB3-3.10.5-py2.7-linux-x86_64.egg/persistent/cPersistence.so: undefined symbol: SSLv2_method
It's hard to see what's going on since it's a binary file. I also tried updating to ZODB3 3.11.0 which yields the following traceback
.buildout/eggs/ZConfig-2.9.0-py2.7.egg/ZConfig/loader.py", line 217, in schemaComponentSource
package=package)
ZConfig.SchemaResourceError: could not load package ZServer:
.buildout/eggs/zope.security-3.7.4-py2.7-linux-x86_64.egg/zope/security/_proxy.so: undefined symbol: SSLv2_method
Package name: 'ZServer'
File name: 'component.xml'
Package path: None
Is there any workaround for this other than reverting OpenSSL?
zope security is a compiled egg, like all the ones ending with -py2.7-linux-x86_64.egg.
As the traceback says, it cannot find anymore a symbol.
Probably you have to recompile it with the new openssl-dev.
I would try (on a development server first):
backup your compiled egg (mkdir eggs-backup && mv `eggs/zope.security-3.7.4-py2.7-linux-x86_64.egg eggs-backup/)
rerun buildout
This will recompile your missing egg.
Hopefully it works and hopefully it is the only one linked to that library.
Anyway, dependending on the way you patched openssl you may have a lot of other issues (I am thinking about Python, urllib*, curl, wget, ...)
OpenSSL 1.0.2g by default doesn't build with SSLv2 (because of the recent DROWN attack). You may need to manually build it without OPENSSL_NO_SSL2 flag.
(but in fact you shouldn't do this if you're doing some server-related stuff, there is a serious security reason because of which it was disabled, see https://drownattack.com)
I was able to resolve this by upgrading python to 2.7.10+, and then upgrading Pillow and lxml.
I ran into an odd issue that I cannot fix in any way and I was hoping someone here may have a better understanding of whats wrong;
I am unable to use RWebLogo package - even run the simplest examples due to the same missing Ghostscript error.
e.g. running:
library(RWebLogo)
aln <- c('CCAACCCAA', 'CCAACCCTA', 'AAAGCCTGA', 'TGAACCGGA')
weblogo(seqs=aln, file.out='mylogo.pdf')
Throws this error:
Traceback (most recent call last):
File "/Library/Frameworks/R.framework/Versions/3.1/Resources/library/RWebLogo/extdata/weblogo-3.3/weblogo", line 71, in <module>
weblogolib._cli.main()
File "/Library/Frameworks/R.framework/Versions/3.1/Resources/library/RWebLogo/extdata/weblogo-3.3/weblogolib/_cli.py", line 82, in main
formatter(data, format, opts.fout)
File "/Library/Frameworks/R.framework/Versions/3.1/Resources/library/RWebLogo/extdata/weblogo-3.3/weblogolib/__init__.py", line 757, in pdf_formatter
gs = GhostscriptAPI()
File "/Library/Frameworks/R.framework/Versions/3.1/Resources/library/RWebLogo/extdata/weblogo-3.3/weblogolib/__init__.py", line 196, in __init__
raise EnvironmentError("Could not find Ghostscript on path."
EnvironmentError: Could not find Ghostscript on path. There should be either a gs executable or a gswin32c.exe on your system's path
I have installed ghostscript ver 9.15 with configure/make/install in the terminal and then added the PATH to bash profile and executed it. When I run gs in the terminal it works, confirming it is set to the system path, yet the same error still occurs. Even after rebooting.
I tried adding the gs to the environment in R directly:
Sys.setenv(R_GSCMD = "/Applications/ghostscript-9.15/bin/gs")
which also hasn't helped... Gives exactly the same error. When I search the R environment it shows that gs is there.
Important version information:
MAC: OS Yosemite 10.10.1;
R version 3.1.1 (2014-07-10);
Platform: x86_64-apple-darwin10.8.0 (64-bit);
RWebLogo_1.0.3
Do you know of any issue that may have cause this problem? I'm new to programming, so I am worried I may be missing something basic. I would be grateful for any advice. Thank you!
I have gotten in touch with Omar, the author of RWebLogo, and he has been really helpful in pinpointing my problems and resolving the issue.
First, he advised to run the RWebLogo on a test sequence on the terminal:
/Library/Frameworks/R.framework/Versions/3.1/Resources/library/RWebLogo/extdata/weblogo-3.3/weblogo -f test_seqs.txt -o ~/Desktop/out.pdf -F pdf
Change the base directory (everything before extdata/weblogo …) of the script above to be whatever the command below gives you in R:
system.file(package = 'RWebLogo')
I ran it and got a new error: the lack of numpy. I actually had the numpy installed but without full user privileges. After reinstalling numpy, the RWebLogo was successfully running from the terminal.
Still, the RStudio was throwing a GhostScript error. Omar suggested that there is a problem with an older version of RStudio running on Yosemite (I currently have 10.10.1), and sent me a link to an updated RStudio version where the problem was fixed.
http://www.r-bloggers.com/r-and-rstudio-incompatibility-with-yosemite-mac-os-x-10-10/
I got the updated RStudio and everything works great there right now. Hope this helps someone with a similar issue!
I'm using Plone 4.1 and trying to run bin/buildout in a fresh directory, having just managed to get python bootstrap.py --distribute to work. bin/buildout runs along fine for a couple of minutes, downloading various distributions, then crashes with the following report:
Getting distribution for 'plone.recipe.zope2instance==4.1.7'.
Got plone.recipe.zope2instance 4.1.7.
... (many distributions omitted for brevity) ...
Getting distribution for 'zope.container==3.11.2'.
Got zope.container 3.11.2.
Getting distribution for 'zope.configuration==3.7.4'.
error: Not a recognized archive type: /Users/Jon/.buildout/downloads/dist/zope.configuration-3.7.4.zip
An error occured when trying to install zope.configuration 3.7.4. Look above this message for any errors that were output by easy_install.
While:
Installing.
Getting section instance.
Initializing section instance.
Installing recipe plone.recipe.zope2instance.
Getting distribution for 'zope.configuration==3.7.4'.
Error: Couldn't install: zope.configuration 3.7.4
It looks like the important error message is: Not a recognized archive type: /Users/Jon/.buildout/downloads/dist/zope.configuration-3.7.4.zip
Incidentally, I tried simply re-running bin/buildout and it picked up in a new place, starting with:
Getting distribution for 'zdaemon==2.0.4'.
Got zdaemon 2.0.4.
Getting distribution for 'pytz==2011g'.
Got pytz 2011g.
...and so on. Can I just keep retrying the script until it successfully get all the stuff that it needs?
Also, I tried running bin/buildout for version 4.2 in another directory, and that seemed to work okay.
EDIT The second time I ran bin/buildout it completed without crashing. However, I did a search of the output and it never once downloaded anything with "configuration" in it's name. So what is going on???
EDIT Just for good measure I tried running bin/buildout a third time and it exited quickly after printing the single line "Updating instance."
You're fine. I suspect you have a less than ideal network connection and/or that PyPI is having problems (one of your other posts was about network related issues as well, I think).
The error you saw is that it's tried to download a zip file that's been corrupted, and so it fails to extract the zip file. On your second attempt, it downloaded it successfully.