feat: Support Python subprocesses

[ichard26]

Pytest-socket should be able to block socket calls in Python subprocesses created by tests (e.g., pip's test suite). To hook into new Python subprocesses, we can use a .pth file to run code during Python startup. This is what pytest-cov does to automagically support subprocess coverage tracking.

State is passed to the .pth file via the _PYTEST_SOCKET_SUBPROCESS environment variable with JSON as the encoding format. Some refactoring was necessary to allow for the right pytest-socket state to be easily passed down to the .pth file (w/o recalculating or rerunning the entirety of pytest_socket.py).

Testing-wise, majority of the tests contained in test_socket.py and test_restrict_hosts.py were copied as subprocess tests. While this doesn't cover every single surface, this should be sufficient to ensure the subprocess support is working properly.

Fixes #401.

[qlty-cloud-legacy]

Code Climate has analyzed commit f080053 and detected 1 issue on this pull request.

Here's the issue category breakdown:

Category	Count
Complexity	1

View more on Code Climate.

[ichard26]

Actually, I'd like to make some more major changes. Also, I'm going to test this against pip's test suite first.

[ichard26]

@miketheman So I just updated my branch, but I am running into an issue. To for this functionality to work, the .pth file needs to installed to the site-packages directory directly. In other words, pytest_socket.pth needs to be its own top-level module in the project. I asked the uv folks (on Discord) and AFAICT, there is no way to configure uv-build to include an additional top level module.

There are no specific wheel includes. There must only be one top level module, and all data files must either be under the module root or in the appropriate data directory.

https://docs.astral.sh/uv/concepts/build-backend/#file-inclusion-and-exclusion

Thus, this feature is dead in the water if this project wishes to use the uv-build backend. I feel bad about asking you to consider switching back to poetry, but that would be necessary to support this feature. I'm sorry that I took so long to update this PR that by the time I got around to it, you made other incompatible changes :(

If you don't want to do that, I'm fine with forking the project and using that in the pip test suite. It wouldn't be too much work on my end. It's your project. It's up to you to manage it.

[miketheman]

Hi @ichard26 ! No worries about timing, sorry that the uv_build backend conflicted with your effort.

Did you get a sense from the uv folks on whether that was something they were considering adding, or a hard no on adding that feature. If it's coming soon, we could wait for it, and then take advantage of it.

Other idea was that uv also commonly uses hatchling build backend - I wonder if that backend would allow the .pth file placement? Maybe we even explore their build-hooks to generate the .pth file (using pytest_socket.embed stuff)?
Refs: https://hatch.pypa.io/1.13/config/build/#build-hooks
Refs: https://hatch.pypa.io/1.13/plugins/build-hook/custom/
I haven't done anything with these ever.

Maybe a combination with https://hatch.pypa.io/1.13/config/build/#rewriting-paths ? I'm not sure, but I'd like to avoid backtracking to poetry if possible.