The library has sat for a while and consequentially no longer was working "out of the box" with VS Code. After doing some investigation, determined the following:
VS Code's latest implementation doesn't pass the items under test to the application anymore. Rather, it calls pytest.main directly
The test runner now blocks (and spins) if it detects a test process is still running
VS Code communicates which tests to run via an environment variable
VS Code injects their own plugin as the first argument passed into pytest. The path is modified to allow running with this plugin
This PR updates everything VS Code. In addition to fixing the ability to run tests, it also updates the dev container configuration.
Note that there is no solution to the test process issue. I noticed that when a test that starts the daemon runs, there's actually two processes that persist, the parent client and the child daemon. However, I noticed that killing the client didn't satisfy VS Code, and it was only satisfied if the daemon was killed as well. Having the tests hang is a bad experience, so I added a parameter for automatically starting the daemon, and now the client will simply error if the server is not running. I plan on raising this issue with the VS Code Python maintainers to see if there's a way we can get these two to cooperate. You can bypass the new logic in VS Code by adding "python.experiments.optOutFrom": [ "pythonTestAdapter" ] to your config.
While double checking whether the hot reloading functionality still worked as expected, I noticed the breakpoint line numbers were no longer lining up like they used to. Jurigged had a bug where functions would have the line numbers drift versus the real ones, and a (large) monkey patch was added to correct the result of the logic. Using the latest version of the library, it appears the monkey patch is now causing the drift, possibly because the issue was fixed since I last checked. I'll investigate this and alter or remove the monkey patch in a different PR. https://github.com/JamesHutchison/pytest-hot-reloading/issues/51 was created
^ Upon investigating it looks like I may have not paid close enough attention and what I thought were breakpoints not hitting were actually it failing to get past MegaPatch.it(...) in the test.
Dev Container Changes
Added mypy extension (not the official one, which sucks)
Switched formatting provider to ruff
The pytest daemon is now automatically started in the background on dev container start
Client Changes
The client now uses the pytest config's invocation_params.dir instead of cwd() for giving the current working directory to the server. I'm not sure this changes anything but it seems prudent to do
The client now uses the pytest config's invocation_params.args instead of logic that extracted the params from the command line parameters. This was needed because VS Code no longer was passing the test via the command line and actually I'm really glad this change was made because it cut out a bunch of complexity and lines of code
Client now sends the environment and current path to the server
The amount of time the client waits for the server to start was increased. Previously it would give up after about a second, now it should give up after about 10.
Server Changes
Now takes in environment in JSON form. JSON is used because it was getting serialization errors in some cases when passing a dict
Now takes the path from the client
Plugin Changes
If pytest --help is used, then it will no longer do plugin logic. This was needed because the exception raised by the server not running was a problem.
Added --daemon-start-if-needed parameter with corresponding PYTEST_DAEMON_START_IF_NEEDED environment variable
Background
The library has sat for a while and consequentially no longer was working "out of the box" with VS Code. After doing some investigation, determined the following:
pytest.main
directlyThis PR updates everything VS Code. In addition to fixing the ability to run tests, it also updates the dev container configuration.
Note that there is no solution to the test process issue. I noticed that when a test that starts the daemon runs, there's actually two processes that persist, the parent client and the child daemon. However, I noticed that killing the client didn't satisfy VS Code, and it was only satisfied if the daemon was killed as well. Having the tests hang is a bad experience, so I added a parameter for automatically starting the daemon, and now the client will simply error if the server is not running. I plan on raising this issue with the VS Code Python maintainers to see if there's a way we can get these two to cooperate. You can bypass the new logic in VS Code by adding
"python.experiments.optOutFrom": [ "pythonTestAdapter" ]
to your config.While double checking whether the hot reloading functionality still worked as expected, I noticed the breakpoint line numbers were no longer lining up like they used to. Jurigged had a bug where functions would have the line numbers drift versus the real ones, and a (large) monkey patch was added to correct the result of the logic. Using the latest version of the library, it appears the monkey patch is now causing the drift, possibly because the issue was fixed since I last checked. I'll investigate this and alter or remove the monkey patch in a different PR. https://github.com/JamesHutchison/pytest-hot-reloading/issues/51 was created^ Upon investigating it looks like I may have not paid close enough attention and what I thought were breakpoints not hitting were actually it failing to get past
MegaPatch.it(...)
in the test.Dev Container Changes
Client Changes
invocation_params.dir
instead ofcwd()
for giving the current working directory to the server. I'm not sure this changes anything but it seems prudent to doinvocation_params.args
instead of logic that extracted the params from the command line parameters. This was needed because VS Code no longer was passing the test via the command line and actually I'm really glad this change was made because it cut out a bunch of complexity and lines of codeServer Changes
Plugin Changes
pytest --help
is used, then it will no longer do plugin logic. This was needed because the exception raised by the server not running was a problem.--daemon-start-if-needed
parameter with correspondingPYTEST_DAEMON_START_IF_NEEDED
environment variable