Bug 1503042
Summary: | Import error when trying to load import "pg" module in python3 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | NickPGSmith <NickPGSmith> |
Component: | PyGreSQL | Assignee: | Pavel Raiskup <praiskup> |
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 26 | CC: | hhorak, jmlich83, pkajaba, pkubat, praiskup, tgl |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2017-11-01 13:22:02 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
NickPGSmith@gmail.com
2017-10-17 09:10:20 UTC
This does not seem like an issue with PyGreSQL. If you take a look into the code where the exception is raised: $ cat /usr/lib/python3.6/site-packages/pg/glfw.py ... _glfw = _load_library(['glfw', 'glfw3'], ['.so', '.dylib', '.dll'], ['', '/usr/lib', '/usr/local/lib'], _glfw_get_version) ... From what I can understand pg is just looking in the wrong places. So should this bug be moved to be against Postgres instead? Where does the glfw.py file come from? It's not from core Postgres, for sure. I assume/believe it's from glfw: [root@pooh ~]# rpm -q glfw glfw-3.2.1-3.fc26.x86_64 but it's not clear to me why an OpenGL wrapper is involved in a database access API. Something important I am missing. Do let me know if there is anything I can test; I have a spare machine I can do clean installs etc, if needed. Thanks (In reply to NickPGSmith from comment #4) > I assume/believe it's from glfw: "rpm -qf /usr/lib/python3.6/site-packages/pg/glfw.py" would tell you for sure. > but it's not clear to me why an OpenGL wrapper is involved in a database > access API. Something important I am missing. That bemuses me as well. Hum, curious: [root@pooh ~]# rpm -qf /usr/lib/python3.6/site-packages/pg/glfw.py file /usr/lib/python3.6/site-packages/pg/glfw.py is not owned by any package Perhaps it appeared from when I ran pip3. Perhaps I shoudln't have done that. I might try a clean build. The glfw.py comes from 'pg' package installed by pip, and 'pg' should be patched so it tries to find libglfw.so* under /usr/lib64, too (not only /usr/lib). Upstream report should go here: https://github.com/fogleman/pg https://pypi.python.org/pypi/pg/0.1 OK, I realised what was confusing me here. My desired library, PyGreSQL appears under the namespace "pg". However, the default installation seems to include pg, the Python OpenGL Graphics Framework under the same "pg" namespace. So I removed the graphics framework: pip3 uninstall pg and then installed PyGreSQL: pip3 install pygresql (additionally I had to install the packages: postgresql-devel python3-devel) All good now. (In reply to NickPGSmith from comment #8) > So I removed the graphics framework: > pip3 uninstall pg > > and then installed PyGreSQL: > pip3 install pygresql Just correction, this is actually a result of upstream bug. You _should_ be able to run the 'pg' library against system-default PyGreSQL (without the need to install PyGreSQL with pip. That's the similar issue to: https://github.com/fogleman/pg/pull/5 (IOW, Nick, for your particular issue, it would be nice to have another pull request against upstream; but the project seems to be dead anyways, so I'm just saying..) |