Closed jasperges closed 4 years ago
Nice one, but do still keep the reference to the server so it's clear what "quit()" refers to. It's a little too similar to exit()
which would kill the Python interpreter.
The reason I just call quit()
is twofold:
quit()
on the server and not on the proxy.quit()
function in host.py
. That function does exactly what I need via the proxy_call
wrapper.So I'm not sure how you would like me to change this. By using the proxy_call
wrapper there is an extra safety check to see if the server is actually still alive. Even though the chances are very slim (or even non-existent) that the server is gone when the operator is not cancelled yet, I think it's a good idea to have this check. To keep a reference to the proxy I would have to duplicate this code, which seems like a bad idea.
The example code you shared in #360, didn't work, because it calls quit() on the server and not on the proxy.
Eeek. The terminology here isn't great; the "proxy" wraps the "server" with commands, like quit. Server in this case is Pyblish QML, where Blender is the client.
Looks like I left out a line from my example.
With that, you should be able to call on proxy.quit()
.
While looking what went wrong with 1, I discovered the quit() function in host.py
Double-eeek! I had also not seen this function. It's a context manager for a wrapper of a wrapper for the server. The proxy should be handling where the server has been killer or is missing.
Let's stick with calling proxy.quit()
directly, so that we can migrate away from those free-floating functions that have no business being in host.py
(but should be in ipc/server.py
).
Okay, thanks for clarifying. I completely agree that proxy.quit()
is better. It makes it clear what has to quit.
I have another question: api.current_server()
calls host.current_server()
. Is it okay to directly call current_server()
or do you prefer to do it via api
, so things can be moved around without breaking this code?
And is it okay if I do from . import api
?
So many questions for such a simple thing... :sweat_smile:
The API is only for external use. Internal modules shouldn't call it, unless it's an even higher-level of abstraction than the API (like e.g. pyblish.util
).
Sorry, now I'm confused. Should I use api.current_server()
or just current_server()
?
I would do what other functions in the module do, unless there's a reason not to.
To be on the safe side, I use:
server = _state.get("currentServer")
if server:
proxy = ipc.server.Proxy(server)
proxy.quit()
Looks good, unsure of why the Docker image fails for the tests.. hopefully it's temporary and doesn't involve this change. Thanks @jasperges
This resolves https://github.com/pyblish/pyblish-qml/issues/360