Utils on a remote machine: which approach? #4894
Replies: 3 comments 12 replies
-
Hi @beraldoleal Thanks for opening this discussion. +1 to have a common interface for local and remote hosts. |
Beta Was this translation helpful? Give feedback.
-
Looks like an interesting approach. I don't think I have a strong opinion now. The only thing I can think of is the benefits inside a test. With more spawners added, I don't see much benefit on the test side. On the other hand, I can see the benefit when using it as a utility outside of a test. |
Beta Was this translation helpful? Give feedback.
-
As most of our tests are using some form of networking I could possibly share an opinion I have formed from the larger scale of application of all these approaches. We have some utilities that make use of Trying from all of these (and still keeping pretty much all of them around), I could say that the most extendable approach for us remained using the remote door (which is not fully contributed to and available from aexpect). The main benefit from using it in our case remains the fact that we don't have to create a separate remote class for each normal class we use which could quickly clutter our class hierarchies and is not possible if we would like to run some code from an external library remotely. Here as an example usage: from aexpect import remote_door as door
# initialize aexpect session here
door.run_remote_util(session, 'extlib.subpackage',
'remote_method') will run |
Beta Was this translation helpful? Give feedback.
-
Hi all,
I'm opening this, because I believe we have a repeated pattern here. So I would like to open this discussion before I proceed to a more "drastic" change.
Some (if not all) of our utility methods needs to be executed on a remote host over SSH sometimes by some tests. And right now we are handling this in a ad-hoc manner. For instance
network
utils is doing a more OOP approach with some classes (RemoteHost
andLocalHost()
). But some we try to pass asession
to each method (i.edistro
and #4857).I would love to see a more standard approach across our libraries, for instance using the same approach as in
network
example. And if you think this is a good way to go, we could think about using heritage and extending the baseHost
class or delegating to proper classes with properties.IMO would be nice to have a common interface for local and remote calls, examples:
And if using a remote host, just a different object would need to be instatiated:
For sure I' m missing some important keys and to avoid frustration and regrets during the implementation, I would like to know what are you toughs on this.
Beta Was this translation helpful? Give feedback.
All reactions