[FR] Pytest-xdist should have its own remote agent

[GeorgeFischhof]

[Moved from pytest issue tracker, #2326 (https://github.com/pytest-dev/pytest/issues/2326)]

Hi There,

I started to used pytest not too far ago. And I found the xdist plugin. I would like to run test on a remote windows macine.

I saw in the documentation
(https://pypi.python.org/pypi/pytest-xdist/1.15.0)
the reference for socketserver.py

I checked the source, and found that it is mainly for unix/linux systems.
I tried it on windows 7, python 3.5. I sent only a print command to the remote, and it was printed successfully, but after that it wrote some errors. ...

Then I read the docs further and found that it says that init.py files should put next to my tests as the remoting handles them this way.

So I bet I would be able to rewrite the socketserver.py, but I think it would be better to create an authentic agent.

And of course I would install pytest on the remote as well (to have all the capabilities on the remote too)
As Python is installed on remote, I think there is no reason not install pytest as well.
(instead of socketserver.py third party stuff)

With this the xdist would be more complete.

Kind regards,
George

[RonnyPfannschmidt]

thanks for moving, i'll repeat my comment from the old issue:

completing this is surprisingly hard once more than pylib and pytest are involved,
as such i would like to see a better idea for this first before just implementing a dead end

we basically need a provisioning and a transfer layer as well as base libraries for this

[GeorgeFischhof]

Hi @RonnyPfannschmidt,

I saw some similar tthing to work, but it worked on linux / unix and it used ssh, rsh.
I think a socket server would be a good solution (in order not to implement too much).

But the script should be in xdist develepoers' hand. The one mentioned in the documentation is not looping, just listens once. So it should listen continuously (like sshd in u*x systems)
It would be quite good fro transport. Of course the script must be started by user before using remoting. (I think the one who wants remoting, will be able to start a script)

For the infrastructure I htink pytest and xdist should be installed on remote machine as well as on the master.

Provisioning: the master xdist and the remote one should be able to communicate to each-oder. (one sends some command and the other understands it).
This way filetransfer can be solved (like rsync)

If the files are on the remote, pytest should be executed as normally, then logs must be sent back.

Maybe Python's internal HTTP server can be used for communication: send files with post, and sending commands like rest api.

BR,
George

[RonnyPfannschmidt]

@GeorgeFischhof thanks for the input,

the main reason why the builtin server runs exactly once is, that the serving process also acts as the process running the gateway, it would be a good idea to have a surrounding tools to handle the clean restarts

a systemd socket activation tool or a daemon restarting surrounding tool may be perfect for that,
on unix its also thinkable to just fork

however the critical part a always is finding someone to volunteer the implementation

the hard part about provisioning is not pushing files around, but creating correct matching fully fledged test environments

execnet can surely manage the plumbing, but it should be considered a tool of the plumber, not the plumber itself (simply because it would grow very complex and turn into a very painful maintenance burden)

a coordination with tox and devpi could be beneficial (but i do lack the time to manage that anytime soon)