You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
# ... snipping the import and setup boilerplate.
conn = server.classic_connect()
# A module that exists on the client only.
import useful_module
# Auto inspect useful_module and switch its imported
# modules, functions, built-ins, etc. to the rpyc server's.
rpyc.switch_module(useful_module, conn)
# Run on rpyc server transparently.
result = useful_module.do_something_useful()
print result
# And be able to switch everything back if no connection provided.
rpyc.switch_module(useful_module)
This of course assumes some things, such as the imported modules, functions, etc. used by useful_module are available on the rpyc server.
The biggest benefit I see here, is I can run a module on another host without touching the code or scp'ing it over and referencing conn every time I want to use the module. Most of the module's code that is host agnostic will run on the client, while mostly just the code required to run on the rpyc server is automatically switched to the rpyc server's. (I'm thinking of requirements such as subprocess.Popen, os.listdir, open, and sys.path.)
Once switch_module() is run, useful_module's functions run on the server transparently (when necessary), until you switch back.
I'm new to rpyc, so I'm curious what downsides others will immediately recognize, or if there exists a better way already.
Would anyone else find this feature useful?
I created an early prototype in a few hours that works only on a few modules I'm currently using. Automating this for most use cases seems feasible with python's introspection tools.
The text was updated successfully, but these errors were encountered:
I think this is probably too unreliable and hard to maintain for all but simple cases. A more reliable solution is probably to use a mechanism similar to the one used for the zerodeploy server - i.e. use plumbum to copy over the code. From rpyc/utils/zerodeploy.py:
Take this code for example:
This of course assumes some things, such as the imported modules, functions, etc. used by
useful_module
are available on the rpyc server.The biggest benefit I see here, is I can run a module on another host without touching the code or scp'ing it over and referencing
conn
every time I want to use the module. Most of the module's code that is host agnostic will run on the client, while mostly just the code required to run on the rpyc server is automatically switched to the rpyc server's. (I'm thinking of requirements such assubprocess.Popen
,os.listdir
,open
, andsys.path
.)Once
switch_module()
is run,useful_module
's functions run on the server transparently (when necessary), until you switch back.I'm new to rpyc, so I'm curious what downsides others will immediately recognize, or if there exists a better way already.
Would anyone else find this feature useful?
I created an early prototype in a few hours that works only on a few modules I'm currently using. Automating this for most use cases seems feasible with python's introspection tools.
The text was updated successfully, but these errors were encountered: