Develop Reference

PatoolError Python: problem in unpacking .rar file

I can't unpack a .rar file using patoolib in Python.
I always get the error message:
PatoolError: could not find an executable program to extract format rar; candidates are (rar,unrar,7z),
I'm using macOS, Anaconda Navigator with Spyder IDE, and I have already installed unrar package. I don't understand why patool can't find the executable program and I'm not able to solve this problem.
Can someone tell me how to solve?
EDIT:
The error arises when I call this method, that I defined to unpack both .zip and .rar files:
def unzip_file(path_to_file, out_dir):
# Extracts path_to_file in out_dir
if path_to_file[-3:] == 'zip':
with zipfile.ZipFile(path_to_file, 'r') as zip_ref:
zip_ref.extractall(out_dir)
return
if path_to_file[-3:] == 'rar':
patoolib.extract_archive(path_to_file, outdir=out_dir)
return
raise FileNotFoundError(path_to_file)

You're on macOS, you should probably installHomebrew if it's not installed, and then run brew install 7z and try again.
I'm guessing that this tool you're using doesn't do the actual archiving, it just knows how to talk to the various archive programs out there, and so you need to have installed one that can read and write RAR archives.

Pyinstaller does not create functional executable with pdfrw

I'm trying to create an executable file using pyinstaller, but it crashes immediately upon launching that executable. It should be noted that the program works perfectly fine inside of PyCharm. I've narrowed it down to only one line of code that causes it to error using another python file - if the file contains
'''import pdfrw'''
it will crash immediately upon launching the executable file created by pyinstaller.
I've tried the following commands from a command prompt running in administrator mode, all of which give that same result (this is after changing the directory to where the .py file is located):
pyinstaller "compiling test.py"
pyinstaller --onefile "compiling test.py"
pyinstaller --onedir "compiling test.py"
Using a try/except clause around the import statement, I'm able to see the error message before it closes the executable, and it says:
Cannot load native module 'Crypto.Cipher._raw_ecb': Trying '_raw_ecb.cp36-win_amd64.pyd': cannot load library 'C:\Users\KYLE~1.AFF\AppData\Local\Temp_MEI534042\Crypto\Util..\Cipher_raw_ecb.cp36-win_amd64.pyd': error 0x7e. Additionally, ctypes.util.find_library() did not manage to locate a library called 'C:\Users\KYLE~1.AFF\AppData\Local\Temp\_MEI534042\Crypto\Util\..\Cipher\_raw_ecb.cp36-win_amd64.pyd', Trying '_raw_ecb.pyd': cannot load library 'C:\Users\KYLE~1.AFF\AppData\Local\Temp_MEI534042\Crypto\Util..\Cipher_raw_ecb.pyd': error 0x7e. Additionally, ctypes.util.find_library() did not manage to locate a library called 'C:\Users\KYLE~1.AFF\AppData\Local\Temp\_MEI534042\Crypto\Util\..\Cipher\_raw_ecb.pyd'
Is there a way I can modify the spec file to make the file correctly (or another solution)? I found something similar when I needed to make an executable with python-docx (and I will most likely need to do this for this program as well, as the original python program I'm trying to make an executable uses python-docx as well as pdfrw): PyInstaller and python-docx module do not work together
Thanks for your help in advance.

So I just found a solution to this! It tipped me off when it was going down a user path named \KYLE~1.AFF\ because that user shouldn't exist, though somehow it got created. After removing that user file, I upgraded pyinstaller via pip install --upgrade pyinstaller, and it uninstalled version 3.3.1, and installed version 3.6, and now it works fine. So possibly it was the new version, but I'm guessing it was more likely the fresh install after I removed the user directory that shouldn't have existed. Not sure why it only errored out with that one library though.

Use C++ dll in pycharm

I’m writing some python code for which I need to access a c++ dll(.so file)
I’m working on pycharm and I’ve already added the library path to my project by following these steps: (settings>project interpreter>Add new interpreter path)
when i run the code
self._bridgeLink = cdll.LoadLibrary(‘foo.so’)
Or
self._bridgeLink = cdll.LoadLibrary(‘./foo.so’)
It gives me an error saying
OSError: foo.so : cannot open shared object file: No such file or directory

The error you are posting suggests that your .so file is not next to your working directory. Try an absolute path to the .so file for testing for now.
You should also check which compiler was used to compile python, you should use the same major version is the Compiler (there are some exception, but that's not the problem for now)

ImportError: bad magic number in 'time': b'\x03\xf3\r\n' in Django

I got this error while running the Django app file that I had downloaded from GitHub. How can I solve this problem?

Please go to your home directory. And then:
sudo find . -name "*.pyc" -exec rm -f {} \;

Finally, I found the answer, The project has .pyc files, which holds the previous version information and time date, so this error. After deleting those files I got the output.

You can delete all the .pyc files in your folder to resolve it.
find . -name \*.pyc -delete

Included in your checkout are .pyc files. These are byte cache files, storing cached bytecode so Python can avoid having to parse and compile the source files. Unless you plan to distribute a project without source files, these should not be included.
Just delete all .pyc files located in the same directory as .py files.
The "magic number" in the error message is a version number for the bytecode stored, and specific Python versions only work with specific bytecode magic numbers; the number in your error is equal to 62211 in decimal (when interpreted as a little-endian number), which shows the .pyc files were created with a Python 2.7 interpreter.
Python 3.2 switched to storing .pyc files in separate __pycache__ directories and including the Python version in the filename. However, any .pyc files still located next to the .py files are supported still to allow for bytecode-only releases. It's safe to delete such files because if you were to use a Python 2.7 interpreter in future, then the files will be re-created.

Delete the .pyc files created in your directory .'
ex : i have gitlab.py and gitlab.pyc
later i renamed it into gitlab-api.py
But while running python file , it is using gitlab.pyc so
Traceback (most recent call last):
File "gitlab-api.py", line 1, in
import gitlab
ImportError: bad magic number in 'gitlab': b'\x03\xf3\r\n'
it worked correctly when i deleted the gitlab.pyc

you will need to delete any pyc. pyc is the cache of your app. delete all files that end with .pyc and rerun your app.

If your OS is Windows you have to delete Python's older versions, then you are ready to use pip again. This is the best method, without errors.

Rename the class name or file name that you are importing, this fixed my issue.

Compiling the Python Interface for Caffe using CMake

On Ubuntu, I have downloaded Caffe to ~/caffe, and compiled it using cmake with the CMakeLists.txt file that it comes with. I now want to start using the python interface. According to the examples, I need to add ~/caffe/python to the PYTHONPATH variable in my .bashrc file. Then, I need to use use import caffe in a python script. However, this gives me the error: ImportError: No module named 'caffe'.
If I use the line import caffe in my python script, this means that there must exist a file called caffe.py in the directories defined by PYTHONPATH. Is that correct? However, I cannot find any files called caffe.py on my system. But the CMakeLists.txt file is supposed to build the python files, and has the line add_subdirectory(python).
Does anybody have any experience with this? Had anybody got the python interface working by compiling with cmake?
Thanks.

You do not need to have caffe.py in ~/caffe/python. In this case you should have a subfolder ~/caffe/python/caffe that should have __init__.py file in this subfolder. Make sure you have ~caffe/python/caffe/_caffe.so file - this shared object should be created during compilation.
It may be the case that you added the right folder to your .bashrc, but have you loaded/sourced the file after updating it?