Neil Botelho

It'll also require a some type of mutex like `threading.RLock` to prevent 2 threads from trying to print to stdout at the same time. That becomes trickier to support since...

Could you elaborate? Currently, if we are downloading sequentially the main thread will just download 1 url at a time so a mutex isn't really needed. In thr case of...

Ah I see. > its easier if you have all the display logic in a single thread which is fed progress events by the download threads. That is how it...

> We seem to be adding a lot of complexity (progress bar subclasses, an now locking mechanisms) for getting "prettier" output, without looking at the bigger picture of what exactly...

> rich does support parallel progress bars already and it's unclear why we need this complexity here. The reason why I felt rich's default parallel progress bar was not suitable...

> Can someone show (even if it's just a mockup somehow) what the end goal of the display is here? I made a test integration of this PR and #12388,...

I haven't had a chance to work on this in a while. I see someone else has opened a PR that solves this issue in a cleaner way, so I'm...

> Great work! Do you have a link to your other PR for the progress bar change? Yep here it is: https://github.com/pypa/pip/pull/12404

@pradyunsg no issues! I totally undestand, and I appreciate the transparency. I'm just happy to finally be contributing back to pip :)

> I wonder how this should be unit-tested. One option to test this would be to unit test the `_download_parallel` method of `BatchDownloader` by adding `Links` for 2 packages. I...