Hi Holger, Alfredo,
if its going to be that generic, then a fit name might be cmdrun-d
as a generic utility that listens for shell escaped lines on a
socket/stdin and executes them with stdout/err of the shell
if that mode of operation is used, the tool could be as simple as a
#!/usr/bin/python
import sys, shlex, subprocess
for line in sys.stdin:
cmd = shlex.split(line)
result = subprocess.call(cmd)
if result:
print(str(cmd) + "Failed")
# -- ronny
On 03/06/2013 07:40 PM, holger krekel wrote:
On Wed, Mar 06, 2013 at 10:04 -0500, Alfredo Deza wrote:
I was looking into passing a path (which can contain some options as well)
to a foreground py.test process that is "listening" for commands to run.
This would help integrate text editors easily send a non-blocking test to
the terminal so that further interaction can take place there. Complex
tests that take very long (or need debugging via pdb) can be very
problematic to run from an editor.
Most editors don't have a terminal emulator, so it is either cumbersome or
impossible to jump from the editor to the shell. Having a foreground
py.test process would help here.
The context would look similar to this:
$ py.test --foreground --listen=/some/socket
============= foreground process starts =============
platform darwin -- Python 2.7.2 -- pytest-2.3.4
listening on: /some/socket
And then from an editor some utility would send the desired path with
options:
utility '-s /path/to/test_file.py' --socket=/some/socket
The listener would then receive the above command and execute:
received test task
collected 1 item
/path/to/test_file.py .
========== 1 passed in 0.01 seconds ==========
And then it would again keep listening for more "tasks". The scenario above
is very simple, but as things get complicated, with more options (like
dropping to pdb) it gets more useful.
On IRC Ronny mentioned that this would be very tricky to accomplish
(probably issues with the import cache). So this would mean that currently,
a plugin would just not be suitable?
As ronny already hints at, i think the listening foreground process
would receive test paths to run along with options, but it would not
even import "pytest" or any of the test files itself. Instead it invokes
a "py.test [options] testpaths" subprocess (passing through
stdin/stdout/stderr) and passing back return values.
Such a listener process could be rather simple and probably shouldn't
be a plugin (after all we don't even want to "import pytest" in it).
It should rather be a "pytest-wrapserver" script and i assume it would
be a rather simple thing to do, no changes to pytest required.
Unless i am missing something, of course :)
holger
Are there any options that would be left for such a thing? If not coming
directly out of py.test maybe a wrapper would probably work here but I am
not aware of any tool that may help.
Any ideas/feedback would be great.
-Alfredo
_______________________________________________
Pytest-dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/pytest-dev
_______________________________________________
Pytest-dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/pytest-dev
_______________________________________________
Pytest-dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/pytest-dev
