I would like to know what pip is sending to a simple repo

[girdevstack]

What's the problem this feature will solve?

I am attempting to debug a difference in install success using a private certificate protected simple repo between a bare-metal account and a docker container. The environment appears to be the same in all of the various ways that I have looked, but inside the container when I run pip install <pkg name> pip reports that it Could not fetch URL <the url and package path> : bad request 400 and then reports that the repo will be skipped. It then continues on and states that no compatible package was found. I've gotten similar results with the 5 most recent versions of pip using python 3.11.1.

Describe the solution you'd like

I would like a flag or arg to include the request that was sent to the remote repository so that I can compare between the two install attempts to see specifically what is being done different between the two.

Alternative Solutions

I have used debug arguments, verbosity up to three Vs, compared the certs with curl and the python ssl package, checked directory and user permissions, verified that the repo is up and contains the package, etc. I have used cli args as well as setting values in a pip.conf file that when I look at the pip config or pip debug it appears that everything is being loaded and read as needed. I've not tried yet, but I'm planning on trying to use wireshark or the browser dev tools with jupyter to see the requests that are being sent out -- but I don't know if anything will be manipulated in a way that isn't representive of how the request is sent from the CLI.

Additional context

In the past I've experienced strange transient issues with permissions in the past, I suspect that maybe something like that is happening but since I haven't been able to dump out the request that pip is sending, I am guessing in the dark. From what I've seen looking through past issues in this repo it looks like most folks have experienced issues with their certs or supported TLS versions, but the http code they have is something other than bad request 400.

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[notatallshaw]

While a PR to add useful debug logging will likely be accepted, a lot of the stuff you're talking about here occurs at a lower level than pip or is outside the pip process.

bad request 400 is a response from the server, so if you have access to the server you would be best looking at the server logs to see what is going wrong.

Otherwise for inspecting HTTP(S) traffic I would look at something that can intercept the traffic either by monitoring the process or as a proxy, it's not something I have done in a while, but there are many tools out there to do that, doing a quick google search (not endoring any of these) I see https://httptoolkit.com/python/ and https://github.com/mitmproxy/mitmproxy and https://portswigger.net/burp/documentation/desktop/getting-started/intercepting-http-traffic.

[girdevstack]

Thank you for the feedback ^_^, I know a decent amount of this issue is specific to my environment so I tried to shy away from that aspect and focus on the utility of being able to review that request as it goes out from pip. You do mention an interesting thing though: if this is likely to be something that is occurring outside pip or somewhere lower in the python(?)/OS stack - would there be some other part of the data flow that it might make sense to dig into or submit a request to as well?