__init__.py cannot dynamically locate version.py (PyKMIP client in docker container)
Closed this issue · 2 comments
As the title states; my pykmip client init.py file cannot locate the version.py file. This error occurs on a client script inside of a centos 8 docker container, and it is worth noting that the same script operates as expected (pulls down a key from the KMIP server) when executed outside of a container on a centos 8 host machine.
See traceback below:
Traceback (most recent call last):
File "main.py", line 12, in
File "", line 971, in _find_and_load
File "", line 955, in _find_and_load_unlocked
File "", line 665, in _load_unlocked
File "PyInstaller/loader/pyimod03_importers.py", line 546, in exec_module
File "kmip/init.py", line 31, in
FileNotFoundError: [Errno 2] No such file or directory: '/tmp/_MEIuB4CYE/kmip/version.py'
[774] Failed to execute script 'main' due to unhandled exception!
What I've tried so far:
-
double checked dependencies, as I think the problem could be the container being configured differently to the host.
Possible I'm missing a package but if I am, I can't figure out what. -
determine if the client can communicate with the KMIP server from within the container.
(it can, turning off the KMIP server produces a connection error). -
Statically assign the path to the version.py file in init.py - I modified this in the code then installed PyKMIP from source.
Strangely the same issue occurs, the application still looks for a folder in /tmp/ directory. -
Create the folder the application is looking for and place version.py within - this was the most obvious workaround.
The folder name is semi-randomly assembled and it's different every time, making this impossible.
Any assistance or advice would be appreciated!
It turned out that the issue was not PyKMIP related, rather it was a execution order error on my part - the step to build my application binary in my dockerfile executed prior to the step which installed PyKMIP, so the binary was produced in an environment with no PyKMIP - complete with the path errors one would expect.
Hi @AB442, thanks for the update. I hadn't had time to look into this before you updated, so I'm glad you were able to find the fix. Cheers!