Remote module to load librarys remotely

[GoogleCodeExporter]

I've modified the remote library to use the local libraries and eliminate the 
need to put libraries on the remote machine.  Libraries are then transfered 
over xmlrpm and loaded on the remote machine.  

Here is the technique that was used: 
http://code.activestate.com/recipes/305277-import-modules-from-a-remote-server/

If this 'enhancement request' gets accepted, I can share my patch.  

Original issue reported on code.google.com by gdwar...@gmail.com on 12 Jul 2010 at 11:30

[GoogleCodeExporter]

As I commented this on robotframework-devel [1], the idea is really 
interesting. I'd like to see the patch before making any decisions, though.

[1] 
http://groups.google.com/group/robotframework-devel/browse_thread/thread/c9f37e7
733f35e73/12465dbdd82c5735#12465dbdd82c5735

Original comment by pekka.klarck on 30 Aug 2010 at 4:15

[GoogleCodeExporter]

Original comment by pekka.klarck on 20 Sep 2010 at 1:49

• Changed state: Pending

[GoogleCodeExporter]

I would love to see this feature implemented. That would mean all we need from 
the remote system is to start the remote server, and everything else can be 
done in the local system. That would really help in the distributed testing!

Original comment by eileen.l...@gmail.com on 27 Sep 2010 at 2:10

[GoogleCodeExporter]

I am wondering if any decision has been made about this patch? And I would love 
to try it before it gets officially released if that's possible :)

Original comment by eileen.l...@gmail.com on 27 Sep 2010 at 2:31

[GoogleCodeExporter]

Here's what I have.  The patch also includes the implementation for the 
enhancement I suggested in 582 (which was rejected).  I'll separate them when I 
have more time.

Original comment by gdwar...@gmail.com on 1 Oct 2010 at 5:38

Attachments:

• robot_patch.diff

[GoogleCodeExporter]

Also here (without 582):
http://bitbucket.org/gdw2/robot-framework

Original comment by gdwar...@gmail.com on 1 Oct 2010 at 7:15

[GoogleCodeExporter]

Sorry I am not sure how to get the patch. Where can I get the files that are 
changed and possibly some documentation and examples?

Original comment by eileen.l...@gmail.com on 5 Oct 2010 at 8:55

[GoogleCodeExporter]

Eileen, can you explain what you've tried in your effort to get the patch?  If 
I learn where you had trouble, maybe I can help.

Original comment by gdwar...@gmail.com on 5 Oct 2010 at 11:05

[GoogleCodeExporter]

Hi Greg,

This is what I have tried - 

1. From http://bitbucket.org/gdw2/robot-framework I did "get source" zip, then 
unzip the folder to D:\robot-framework-c024ad337e52
2. Copy 
D:\robot-framework-c024ad337e52\robot-framework\src\robot\libraries\RemoteB.py 
to C:\Python27\Lib\site-packages\robot\libraries
3. Copy 
D:\robot-framework-c024ad337e52\robot-framework\tools\remoteserver\robotremotese
rverB.py to my remote Win7 machine
4. In the remote machine command window
   >python robotremoteserverB.py vmw1223-w71 (Note that vmw1223-w71 is the remote machine name)
5. In the local machine I created new_remote_tests.html as attached. Note that 
I have created c:\Test\TestFiles directory in the remote machine and added a 
few files to it.
6. Here is what I got when running the test from the local system (Win7):
>pybot new_remote_tests.html
> c:\python27\lib\site-packages\robot\libraries\remoteb.py(113)remote_import()
-> raise
(Pdb)

What went wrong?

Thanks,
Eileen

Original comment by eileen.l...@gmail.com on 6 Oct 2010 at 5:40

Attachments:

• new_remote_tests.html

[GoogleCodeExporter]

I've never tested it on windows.  I don't know if that may be a factor.  

I highly recommend getting my provided example working first.  (see 
doc/examples/remoteb/xmlrpc.rst).  Then again, it's obvious by looking at the 
example that it is unix-specific.  

So the chance that this will work flawlessly for your situation with no 
digging-into-the-code effort on your part is pretty minimal.  Sorry.

Original comment by gdwar...@gmail.com on 6 Oct 2010 at 10:23

[GoogleCodeExporter]

I don't have a unixy system to try it on, but that's ok because I am going to 
use a solution suggested by Frank in here: 
http://groups.google.com/group/robotframework-users/browse_thread/thread/3b23280
aaf3d6b7c. And will try this one again if it gets put into a future release.

Thanks for the help!

Eileen

Original comment by eileen.l...@gmail.com on 7 Oct 2010 at 2:49

[GoogleCodeExporter]

Glad to hear.

Original comment by gdwar...@gmail.com on 7 Oct 2010 at 3:44

[GoogleCodeExporter]

Hi Eileen, 

I can't access 
http://groups.google.com/group/robotframework-users/browse_thread/thread/3b23280
aaf3d6b7c. Could you share it to me again?
My mail is xuedipiaofei@gmail.com

Original comment by xuedipia...@gmail.com on 21 Feb 2011 at 1:16

[GoogleCodeExporter]

Hi Greg,
It can't avoid the same name keyword problems if loading all the libraries at 
one time. 

Original comment by xuedipia...@gmail.com on 22 Feb 2011 at 6:27

[GoogleCodeExporter]

What's the status of this enhancement?  
I know this probably isn't the best solution for duplicate keyword names but it 
might be a good start.

You could start an XML RPC server on say port 8270 and have it serve a 
RemoteLibLoaderLibrary which has one function 'export' which would take in a 
port and a library.  The return value of 'export' could be the port on which 
the newly loaded library is running on.  This way you could specify a Library 
name client side when importing a Remote library and you won't have the 
ambiguous keyword name problem.

The ideal solution would allow you to load a library and specify a Library name 
and perhaps the remote XML RPC server would have a get_library_names(self) and 
change the other functions to something like get_keyword_names(self, 
libraryName).  Then the keyword look up would have to be enhanced to resolve 
library names residing on the remote server.

Original comment by brut...@gmail.com on 4 May 2011 at 2:42

[GoogleCodeExporter]

I haven't used robotframework for some time so I personally am not pursuing 
this.

Original comment by gdwar...@gmail.com on 4 May 2011 at 3:23

[GoogleCodeExporter]

This is useful functionality but I think it's better to implement it outside 
the core framework. We couldn't use the same approach with other than the 
Python remote server anyway, and that server is nowadays implemented as a 
separate project anyway.

Original comment by pekka.klarck on 24 Jun 2014 at 9:29

• Changed state: WontFix