I am getting the following error when I try to run gtfs_realtime_pb2.py (the python code generated from running the gtfs-realtime.proto through google's protocol buffer):
Traceback (most recent call last):
File "<pyshell#1>", line 1, in <module>
from google.protobuf import descriptor
ImportError: No module named 'google'
This is a link to the specific code I am having trouble with:
https://github.com/mattwigway/gtfsrdb
And the link to installing google's protocol buffer:
https://developers.google.com/protocol-buffers/
I am pretty certain I have install the buffer correctly, so why is it throwing up that it can't find this module?
Included in protocol buffer is descriptor.proto; python code for this proto should of been generated as part of the install process.
The protocol buffer you are using uses descriptor.proto so the directory where it resides needs to be included via the --proto_path= parameter (see Importing "google/protobuf/descriptor.proto" in java protocol buffers
For window systems, the install directory will be where you placed it; for *nix it will probably be answer taken from
/usr/include/descriptor.proto
or
/usr/local/include/descriptor.proto
i.e. for java you would do something like
protoc addressbookSD.proto --java_out=./ --proto_path=./ --proto_path=<protobuf-install-directory>/src
where <protobuf-install-directory> is the protocol buffers install directory. The key point is descriptor.proto is in
<protobuf-install-directory>\src\google\protobuf
Related
I'm working in a project involving the Raspberry Pi and the PiFace interface module. The project is being developed in Python and I have run into a problem when trying to auto document some modules with Sphinx. We are using the pifacedigitalio library, however, even though I have installed said library on the development machine, Sphinx refuses to document the module and complains that it's throwing exceptions due to hardware not being present. The hardware isn't present because this is the development machine. For testing the software, we just use a conditional if hwpresent then skip but I actually want to document those parts through Sphinx. The error produced when doing make html is:
/home/user/current/working/docs/src.rst:10: WARNING: autodoc: failed to import module u'src.billete'; the following exception was raised:
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/sphinx/ext/autodoc.py", line 335, in import_object
__import__(self.modname)
File "/home/user/current/working/src/bill.py", line 4, in <module>
piface_obj = piface.PiFaceDigital()
File "/usr/local/lib/python2.7/dist-packages/pifacedigitalio/core.py", line 82, in __init__
self.init_board()
File "/usr/local/lib/python2.7/dist-packages/pifacedigitalio/core.py", line 107, in init_board
h=self.hardware_addr, b=self.bus, c=self.chip_select))
NoPiFaceDigitalDetectedError: No PiFace Digital board detected (hardware_addr=0, bus=0, chip_select=0).
Is there a way to avoid Sphinx from interpreting the code and just parse the source? I tried to modify pifacedigitalio/core.py by hand using dummy returns but Sphinx just freezes then.
You have to put a directory in your PYTHONPATH that has Mock's of those modules before you run Sphinx. Check out their Doc's, but be warned that you shouldn't be screwing around with sys.modules yourself like they do in the example. Use mock.patch instead.
So I used pip to download filemagic:
E:\cuckoo-current\cuckoo>c:\Python27\Scripts\pip.exe install filemagic
Downloading/unpacking filemagic
Downloading filemagic-1.6.tar.gz
Running setup.py (path:c:\users\vaclav~1.vas\appdata\local\temp\pip_build_vaclav.vasenka\filemagic\setup.py) egg_info for package filemagic
Installing collected packages: filemagic
Running setup.py install for filemagic
Successfully installed filemagic
Cleaning up...
I've created test.py with content:
import magic
print "test"
And when I run the file import throws exception:
Traceback (most recent call last):
File "E:\sand\test.py", line 2, in <module>
import magic
File "C:\Python27\lib\site-packages\magic\__init__.py", line 18, in <module>
from magic.identify import Magic, MagicError
File "C:\Python27\lib\site-packages\magic\identify.py", line 16, in <module>
from magic import api
File "C:\Python27\lib\site-packages\magic\api.py", line 22, in <module>
raise ImportError('Unable to find magic library')
ImportError: Unable to find magic library
Is the filemagic corrupted ? Is this module even working ?
From the PYPI Description (emphasis mine)
A Python API for libmagic, the library behind the Unix file command
and
libmagic is the library that commonly supports the file command on
Unix system, other than Max OSX which has its own implementation. The
library handles the loading of database files that describe the magic
numbers used to identify various file types, as well as the associated
mime types. The library also handles character set detections.
You cannot use this on Windows, as you are attempting.
You can attempt to use the mimetypes module in the standard library (mimetypes.guess_type would be what to look at).
I faced the same problem with docker containers with Alpine Linux image:
It seems like in Alpine Linux the library search doesn't work, hence it fails to find 'libmagic.so.1' which is required for the working of magic library( dependency filemagic and libmagic).
Workaround:
Use Python slim instead of Alpine Linux
mime, mimetypes are the other python libraries which can be used (the only downside to these two libraries is, that they find the mime type based on file extension and not file headers.
So I am having trouble compiling a very simple python script using JPype.
My code goes like:
from jpype import *
startJVM(getDefaultJVMPath(), "-ea")
java.lang.System.out.println("hello world")
shutdownJVM()
and when I run it I receive an error saying:
Traceback (most recent call last): File "test.py", line 2, in
<module>
startJVM(getDefaultJVMPath(), "-ea") File "/usr/lib/pymodules/python2.7/jpype/_core.py", line 44, in startJVM
_jpype.startup(jvm, tuple(args), True) RuntimeError: Unable to load DLL [/usr/java/jre1.5.0_05/lib/i386/client/libjvm.so], error =
/usr/java/jre1.5.0_05/lib/i386/client/libjvm.so: cannot open shared
object file: No such file or directory at
src/native/common/include/jp_platform_linux.h:45
I'm stuck and I really need help. Thanks!
I had the same problem
RuntimeError: Unable to load DLL [/usr/java/jre1.5.0_05/lib/i386/client/libjvm.so], error = /usr/java/jre1.5.0_05/lib/i386/client/libjvm.so: cannot open shared object file: No such file or directory at src/native/common/include/jp_platform_linux.h:45
In my case wrong JAVA_HOME path was set
/profile/etc
export JAVA_HOME
JAVA_HOME=/usr/lib/jvm/java-6-openjdk-amd64
PATH="$JAVA_HOME/bin:$PATH"
export PATH
The work around is to define the full path directly in the call to the JVM:
from jpype import *
startJVM('/Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/MacOS/libjli.dylib', "-ea", "-Djava.class.path=/tmp/Jpype/sample")
java.lang.System.out.println("Hello World!!")
shutdownJVM()
Original text:
Similar issues when trying to run JPype on MacOS El Capitan. I could
not figure out how to coax the _darwin.py code finding the correct JVM
location, despite the JAVA_HOME system variable being set properly.
Caveat cursor, trying to run the above code in the Spyder IPython console did not produce any output, but the normal Console would.
I build python2.6.1 on laptop. Build was successful. After that I tried to run python using ./python and tried to import select module
>>>import select
>>>select.epoll()
<select.epoll object at 0xb76140d0>
After that I copied the python build folder to anther laptop and tried to run python
>>>import select
>>> select.epoll()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'epoll'
How to solve this problem
From the manual:
select.epoll([sizehint=-1])
(Only supported on Linux 2.5.44 and newer.)
Returns an edge polling object, which can be used as Edge or Level Triggered interface
for I/O events; see section Edge and Level Trigger Polling (epoll)
Objects below for the methods supported by epolling objects.
New in version 2.6.
And obviously distromakers can disable it in python build settings or so. It does depend on glibc only as far as I know. Also are you sure you are importing from the system select module, and not from your own module named by the same name? (check select.__file__; as a builtin module it should not have a file ;)
Hy,
Trying to use qooxdoo with debian lenny.
qooxdoo sdk 1.2
create-application.py ok but I've got a problem with generate.py :
/demo/qooxdoo/hello1$ ./generate.py source-all
Traceback (most recent call last):
File "/demo/qooxdoo-1.2-sdk/tool/bin/generator.py", line 26, in <module>
from generator.Generator import Generator
File "/demo/qooxdoo-1.2-sdk/tool/bin/Generator.py", line 31, in <module>
#import warnings
File "/demo/qooxdoo-1.2-sdk/tool/bin/Generator.py", line 31, in <module>
#import warnings
ImportError: No module named code.Class
I do think I'm missing some debian packages
Do please help me. Ta.
This stack trace is a tad weird. For a basic thing, the referenced code line (Generator.py:31) imports from "generator.code.Class", and the ImportError indicates that it doesn't find the "code" subpackage under "generator". But the "#import warnings" line is actually generator.py line 31, as if it would be mixing generator.py and Generator.py.
This is furthered by the fact that the stack trace references /demo/qooxdoo-1.2-sdk/tool/bin/Generator.py, which should really be /demo/qooxdoo-1.2-sdk/tool/pylib/generator/Generator.py
I don't have a lenny handy to check if the package itself is alright, but I get the feeling there is some basic flaw with how the qooxdoo SDK is installed on your machine.
I recommend that you simply download the qooxdoo-1.2-sdk from sourceforge and unpack it to a suitable directory. Then re-run the create-application.py from this package to create a new skeleton, or edit the config.json of your existing skeleton so that the QOOXDOO_PATH macro points to the new SDK. Then you should be all set.
I agree with zamnut6. I've had the same problem when I extracted the qooxdoo SDK package on a a virtualbox shared HFS filesystem. The problem is something to do with file name casing incompatibility between two file systems.
Extracting the SDK on a normal Linux directory (if your development environment is Linux) should solve this issue.
I ran into this problem too when I had unpacked the zip file in a virtual box shared directory (host XP, guest Ubuntu), the share caused this issue when I ran ./generate.py source within the shared directory.
When I unpacked the zip to a normal Linux directory, I had no problems.