I've got a PyDev project that uses protocol buffers. The protocol buffer files are located in a zip file generated by the protoc compiler. Everything works when I run the program, however PyDev reports "Undefined variable from import" for every enumeration constant. So for example:
import model_pb2
value = model_pb2.Expression(type = model_pb2.Expression.PARAMETER)
It reports the enum constant "PARAMETER" as being an undefined variable. There are several dozen similar errors in my program, and I'd like to fix them "properly" (i.e. not simply suppressing the warning.)
I found that using for builtins as can work, but only if all the proto files are in a separate located in an external library (see http://pydev.org/manual_101_project_conf2.html).
This should work:
Move (or unzip) the compiled proto files including model_pb2.py into a directory outside the pydev project.
Add an empty __init__.py file to the same directory as model_pb2.py to ensure it can be imported as a library.
In eclipse, go to Windows -> Preferences -> pydev -> Interpreter
Add the directory with model_pb2.py to the Libraries.
Add model_pb2 to the forced buildins.
If you're not addicted to autocomplete, you may using ctrl+1 to ignoring these errors instead as described in this answer. This was tested with Eclipse Kepler and pydev 2.8.
I encountered this issue with protobuf 2.6.1 and PyDev 4.5.5. I tried the suggestions above both none of them helped in my case. What ended up getting rid of the 'undefined variable' errors when using protobuf enums was simple:
Access the enum on an instantiated protobuf object rather than on the protobuf module.
I'm not sure if this could be applied to the OP's use case, but in mine it was as easy as:
from myprotobuf_module import SomeProtobufMessage
some_protobuf_object = SomeProtobufMessage()
some_enum = some_protobuf_object.SOME_ENUM
Have you tried adding "model_pb2" to your forced builtins? See: http://pydev.org/manual_101_project_conf2.html for details.
Related
I try to use an assembly for .NET framework 4.8 via Pythonnet. I am using version 3.0.1 with Python 3.10. The documentation of Pythonnet is stating:
You must set Runtime.PythonDLL property or PYTHONNET_PYDLL environment variable starting with version 3.0, otherwise you will receive BadPythonDllException (internal, derived from MissingMethodException) upon calling Initialize. Typical values are python38.dll (Windows), libpython3.8.dylib (Mac), libpython3.8.so (most other Unix-like operating systems).
However, the documentation unfortunately is not stating how the property is set and I do not understand how to do this.
When I try:
import clr
from pythonnet import load
load('netfx')
clr.AddReference(r'path\to\my.dll')
unsurprisingly the following error is coming up
Failed to initialize pythonnet: System.InvalidOperationException: This property must be set before runtime is initialized
bei Python.Runtime.Runtime.set_PythonDLL(String value)
bei Python.Runtime.Loader.Initialize(IntPtr data, Int32 size)
bei Python.Runtime.Runtime.set_PythonDLL(String value)
bei Python.Runtime.Loader.Initialize(IntPtr data, Int32 size)
[...]
in load
raise RuntimeError("Failed to initialize Python.Runtime.dll")
RuntimeError: Failed to initialize Python.Runtime.dll
The question now is, where and how the Runtime.PythonDLL property or PYTHONNET_PYDLL environment variable is set
Thanks,
Jens
I believe this is because import clr internally calls pythonnet.load, and in the version of pythonnet you are using this situation does not print any warning.
E.g. the right way is to call load before you call import clr for the first time.
The way I understand your use case is for Embedding .NET in Python however, the way I understand the requirement to "set Runtime.PythonDLL property" is that is for Embedding Python in .NET which was my use case. Anyhow, maybe the following will be useful.
Hidden at the bottom of the main GitHub README.md is a link to the WiKi (and of course the tab at the top of the GitHub repo) where thankfully there is a lot more detailed information and links to useful articles.
The main README.md asserts Runtime.PythonDLL "must be set" yet their example code does not illustrate doing so. Furthermore, the documentation on the official website asserts Python.Runtime.dll must be "referenced" which further confuses things.
In my experience Python.Runtime.dll was automatically referenced when installing the pythonnet NuGet package via Visual Studio. Perhaps Python.Runtime.dll does not automatically get referenced in earlier version or maybe when Python.NET is installed in other ways other than by using NuGet?
To answer your question "how to set Runtime.PythonDLL property?". My understanding is the way that is done is by assigning a string path to that property before the other usual setup:
Runtime.PythonDLL = #"C:\Users\<username>\AppData\Local\Programs\Python\Python310\python38.dll"
In my case, I found this path by using where python on Windows (which in bash, or Get-Command in PowerShell):
C:\>where python
C:\Users\<username>\AppData\Local\Programs\Python\Python310\python.exe
I am trying to run a C function in Python. I followed examples online, and compiled the C source file into a .so shared library, and tried to pass it into the ctypes CDLL() initializer function.
import ctypes
cFile = ctypes.CDLL("libchess.so")
At this point python crashes with the message:
Could not find module 'C:\Users\user\PycharmProjects\project\libchess.so' (or one of its dependencies). Try using the full path with constructor syntax.
libchess.so is in the same directory as this Python file, so I don't see why there would be an issue finding it.
I read some stuff about how shared libraries might be hidden from later versions of python, but the suggested solutions I tried did not work. Most solutions were also referring to fixes involving linux system environment variables, but I'm on Windows.
Things I've tried that have not worked:
changing "libchess.so" to "./libchess.so" or the full path
using cdll.LoadLibrary() instead of CDLL() (apparently both do the same thing)
adding the parent directory to system PATH variable
putting os.add_dll_directory(os.getcwd()) in the code before trying to load the file
Any more suggestions are appreciated.
Solved:
Detailed explanation here: https://stackoverflow.com/a/64472088/16044321
The issue is specific to how Python performs a DLL/SO search on Windows. While the ctypes docs do not specify this, the CDLL() function requires the optional argument winmode=0 to work correctly on Windows when loading a .dll or .so. This issue is also specific to Python versions greater than 3.8.
Thus, simply changing the 2nd line to cFile = ctypes.CDLL("libchess.so", winmode=0) works as expected.
I created a python extension using Boost::Python. To make it easier to use the extension on different target machines, I have included the libboost_python36.so.1.75.0 library in the same directory as the generated extension (pyshmringbuffer.so).
I checked out pyshmringbuffer.so and libboost_python36.so.1.75.0 onto a machine other than it was compiled in the directory : /path/to/pyshmringbuffer
After setting LD_LIBRARY_PATH to: /path/to/pyshmringbuffer and changing to this directory, I am able to run python3.6 and import the shared object just fine.
The problem comes when I try to run python from an alternate directory. From any other directory, I append the python path as follows:
import sys
sys.path.append("/path/to/pyshmringbuffer")
Then, when I try to import pyshmringbuffer, I get the following undefined symbol:
ImportError: /path/to/pyshmringbuffer/pyshmringbuffer.so: undefined symbol: _ZNK5boost6python7objects21py_function_impl_base9max_arityEv
I was under the impression that all symbols are self contained within the shared object. Why does it matter where I import the shared library from?
The symbol in your error message is an internal one, generated by one of the build tools. Having one undefined suggests that one of your components was built with an incompatible tool version, or that a *.so file (shared object) is out of date in some other fashion.
The simplest way to fix this is usually to rebuild your product components from scratch, in the proper order.
I was able to resolve my issue by prepending /path/to/pyshmringbuffer to my python path using:
sys.path.insert(0,"/path/to/pyshmringbuffer")
I can't say for sure, but as #PRUNE pointed out, there is something in my python path that python is seeing before it sees the intended library.
Coincidentally, I DO have a build of libboost_python36.so.1.75.0 located elsewhere on the target machine. The path for this doesn't appear on my PYTHONPATH or LD_LIBRARY_PATH, so I wouldn't EXPECT it to have been interfering, but I can't be positive.
When I import a module I built, I get this boost-python related error:
Traceback (most recent call last):
File "<string>", line 1, in <module>
ImportError: dlopen(./myMod.so, 2): Symbol not found: __ZN5boost6python7objects15function_objectERKNS1_11py_functionERKSt4pairIPKNS0_6detail7keywordES9_E
Referenced from: ./myMod.so
Expected in: flat namespace
in ./myMod.so
What does this actually mean? Why was this error raised?
Description
The problem was caused by mixing objects that compiled with libc++ and object that compiled with libstdc++.
In our case, the library myMod.so (compiled with libstdc++) need boost-python that compiled with libstdc++ (boost-python-libstdc++ from now). When boost-python is boost-python-libstdc++, it will work fine. Otherwise - on computer that its boost-python has compiled with libc++ (or another c++ library), it will have a problem loading and running it.
In our case, it happens because that libc++ developers intentionally changed the name of all of their symbols to prevent you (and save you) from mixing code from their library and code from a different one: myMod.so need a function that take an argument from the type. In libc++, this type's name is std::__1::pair. Therefore, this symbol was not found.
To understand why mixing two version of the same API is bad, consider this situation: There are two libraries: Foo and Bar. They both have a function that takes a std::string and uses it for something but they use a different c++ library. When a std::string that has been created by Foo will be passed to Bar, Bar will think that this is an instance of its c++ library's std::string and then bad things can happen (they are a completely different objects).
Note: In some cases, there would be no problem with two or more different versions of the same API in a completely different parts of a program. There will be a problem if they will pass this API's objects between them. However, checking that can be very hard, especially if they pass the API object only as a member of another object. Also, a library's initialization function can do things that should not happen twice. Another version may do these things again.
How to solve that?
You can always recompile your libraries and make them match each other.
You can link boost-python to your library as a static library. Then, it will work on almost every computer (even one that doesn't has boost-python installed). See more about that here.
Summary
myMod.so need another version of boost-python, one that compiled with a specific c++ library. Therefore, It would not work with any another version.
In my case I was receiving:
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/xmlsec.cpython-38-darwin.so, 0x0002): symbol not found in flat namespace '_xmlSecDSigNs'
BACKGROUND:
M1 MacBook Pro with Montery
I was working with a python virtualenv (using pyenv) to use an earlier version of python3.8 (3.8.2), while my system had 3.8.10 installed natively.
While I was in the activated 3.8.2 virtualenv I noticed the path in dlopen() was pointing to the package in the native python install NOT the virtualenv install.
SOLUTION:
In my case, I did not need the native 3.8 version at all so I simply removed it and this solved the problem.
I encounter the same problem.
Expected in: flat namespace
Add the linker flag fixes the problem
-lboost_python37
change the dynamic library name to the one installed on the os.
By the way, my os is macOS High Sierra and I use brew to install boost_python3.
Symbol not found means the definition of the declared function or variable was not found. When a header file of a shared object is compiled with your program, linker adds symbols of declared functions and objects to your compiled program. When your program is loaded by the OS's loader, the symbols are resolved so that their definition will be loaded. It is only at this time where if the implementation is missing, loader complains it couldn't find the definition due to may be failing to resolve the actual path to the library or the library itself wasn't compiled with the implementation/source file where the definition of the function or object resides. There is a good article on this on the linux journal http://www.linuxjournal.com/article/6463.
In my case I was just failing to import all the required sources (c++ files) when compiling with Cython.
From the string after "Symbol not found" you can understand which library you are missing.
One of the solutions I found was to uninstall and reinstall it using the no-binary flag, which forces pip to compile the module from source instead of installing from precompiled wheel.
pip install --no-binary :all: <name-of-module>
Found this solution here
Here's what I've learned (osx):
If this is supposed to work (i.e. it works on another computer), you may be experiencing clang/gcc issues. To debug this, use otool -l on the .so file which is raising the error, or a suspect library (in my example it's a boost-python dylib file) and examine the contents. Anything in the /System/ folder is built with clang, and should be installed somewhere else with the gcc compiler. Never delete anything in the /System folder.
.so files are dynamic libraries (so = shared object). On Windows they are called .dll (dynamic-link library). They contain compiled code which contains functions available for usage to any executable which links them.
What is important to notice here is that those .so are not Python files. They were probably compiled from C or C++ code and contain public functions which can be used from Python code (see documentation on Extending Python with C or C++).
On your case, well, you have a corrupt .so. Try reinstalling the affected libraries, or Python, or both.
Problem
I had this same issue when running puma as part of Rails app
LoadError:
dlopen(/Users/alucard/.rbenv/versions/2.7.6/lib/ruby/gems/2.7.0/gems/puma-5.6.4/lib/puma/puma_http11.bundle, 0x0009): symbol not found in flat namespace '_ERR_load_crypto_strings'
/Users/alucard/.rbenv/versions/2.7.6/lib/ruby/gems/2.7.0/gems/puma-5.6.4/lib/puma/puma_http11.bundle
Solution
It was solved just by installing puma gem again gem install puma
The only thing I can get python omnicomplete to work with are system modules. I get nothing for help with modules in my site-packages or modules that I'm currently working on.
Once I generated ctags for one of my site-packages, it started working for that package -- so I'm guessing that the omnicomplete function depends on ctags for non-sys modules.
EDIT: Not true at all.
Here's the problem -- poor testing on my part -- omnicomplete WAS working for parts of my project, just not most of it.
The issue was that I'm working on a django project, and in order to import django.db, you need to have an environment variable set. Since I couldn't import django.db, any class that inherited from django.db, or any module that imported a class that inherited from django.db wouldn't complete.
I get completion for my own modules in my PYTHONPATH or site-packages. I'm not sure what version of the pythoncomplete.vim script you're using, but you may want to make sure it's the latest.
EDIT: Here's some examples of what I'm seeing on my system...
This file (mymodule.py), I puth in a directory in PYTHONPATH, and then in site-packages. Both times I was able to get the screenshot below.
myvar = 'test'
def myfunction(foo='test'):
pass
class MyClass(object):
pass
Just ran across this on Python reddit tonight: PySmell. Looks like what you're looking for.
PySmell is a python IDE completion helper.
It tries to statically analyze Python source code, without executing it, and generates information about a project’s structure that IDE tools can use.
While it's important to note that you must properly set your PYTHONPATH environmental variable, per the the previous answer, there is a notable bug in Vim which prevents omnicompletion from working when an import fails. As of Vim 7.2.79, this bug hasn't been fixed.
Trouble-shooting tip: verify that the module you are trying to omni-complete can be imported by VIM. I had some syntactically correct Python that VIM didn't like:
:python import {module-name}
Traceback (most recent call last):
File "<string>", line 1, in ?
File "modulename/__init__.py", line 9
class empty_paranthesis():
^
SyntaxError: invalid syntax
Case-in-point, removing the parenthesis from my class definition allowed VIM to import the module, and subsequently OmniComplete on that module started to work.
I think your after the pydiction script. It lets you add your own stuff and site-packages to omni complete.
While your at it, add the following to your python.vim file...
set iskeyword+=.
This will let you auto-complete package functions e.g. if you enter...
os.path.
and then [CTRL][N], you'll get a list of the functions for os.path.