How to disable logging

[q0w]

The proposed solution of #1089 is to add the custom plugin, which prints access logs. In pypa/pip#11091 windows CI has been worked 6 hours and then failed. I think, I need to disable logging at all, but there is no way to do it.

[abhinavsingh]

@q0w You can remove super() call and it will automatically disable logging from the core, leaving only the print statements as the only logging statement for the instance. https://github.com/pypa/pip/pull/11091/files#diff-35c83feabce838957ec0526f0280604f479df39c03e56ca51b65ed34de098c81R22

However, it's unclear to me why a call to super() results in test failures, specially for windows/1 only runs. Does your test processes stdout/stderr for assertions? I looked at the runs but didn't see any specific error logs. I also see windows/2 passes. Wondering if windows/2 runs is also using proxy.py?

Please let me know if removing super() helps.

[q0w]

num_acceptors=1

Unfortunately no https://github.com/pypa/pip/runs/6906570097?check_suite_focus=true

[abhinavsingh]

TL;DR -- Please use subprocess based strategy which will remove the flakiness/failures happening in Windows environment.

Alternate Way using Subprocess

In the meantime, I'll recommend you to try this approach which cannot be impacted by Windows related join issues and your PR workflows should work fine. This approach uses subprocess to start proxy, instead of embedded mode. More importantly, with this approach, during test teardown, your tests need not wait on acceptor joins. Cleanup of orphaned processes is delegated to GHA automatically.

In-fact, proxy_py_subprocess is a pytest fixture, if you can, you may directly use this fixture in your PR, or extend on top of it.

Let me know if this helps.

About bug in Embedded mode

At this point, I can certainly say, this is flaky on Windows (for proxy.py tests itself) and looks like it never runs for your PR. I say so, because after I merged timeout=1 PR and ran the release job, workflow got stuck for Windows + Python 3.10 :(. Which means timeout=1 is likely not the right fix here, or at-least not the only fix.

To debug this further, I sent out this PR #1199 where I am using acceptor=1. I also reverted the timeout=1 to check if that even was necessary. But looks like num_acceptor=1 ain't working for you either.

Because the workflow gets stuck, I believe issue is related to join. There are more join in the code, I only resolved the acceptor ones. Unsure if one of those are an issue here. It would have been really helpful, if you could, possibly, run the workflow with debug level logging. That will help me get more context.

Further on this, following needs to be tried for deeper inspection:

1. Get a Windows 10 VirtualBox setup locally
2. Try to reproduce by running similar usage pattern multiple times
3. If unable to reliably reproduce still, try to clone ur PR and run that specific test locally on Windows.

[q0w]

Thanks for all your efforts, it was really helpful.

run the workflow with debug level logging.

Unfortunately I have not necessary permissions to do this.

I will try proxy_py_subprocess fixture as you said. Thanks a lot.

[q0w]

My bad, num_acceptors = 1 is fine. I think, it was failed because of 127: as you mentioned.

[abhinavsingh]

Yayyyyyyy!!!!! Thanks for verifying. Happy this has worked out. Just to summarize, it's important to use num_acceptors=1 on windows to avoid join pitfalls.

I will add this in README so that it remains documented under FAQs. Best