Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Show install progress when using --progress-bar=raw #12601

Open
wants to merge 9 commits into
base: main
Choose a base branch
from

Conversation

joeyballentine
Copy link

@joeyballentine joeyballentine commented Mar 27, 2024

This PR is a follow-up to #11508 / #12586 which adds machine-readable install progress outputs.

Right now, unless pip is uninstalling a package to upgrade it, pip does not output any progress information for the actual install process. This means that any GUI wrapping pip cannot accurately display the current progress of the install. For example, if I wanted to be able to display "installing opencv-python", I would have no idea when opencv-python is actually installing. The best I would be able to do would be to display an indeterminate progress spinner and maybe guess where the install progress is at based on the uninstalling messages.

So, this PR solves that issue by outputting the current install progress when the --progress-bar setting is set to "raw". I did try to add a regular progress bar to this as well, but due to the extra logging it does sometimes (like during uninstalls), a regular progress bar is not a good fit for this specific feature. Besides, this is only useful for those who want to display extra information that they cannot currently get from pip's output (which is why someone would be using the "raw" option anyway).

Example screenshot:
image

yes i installed mypy locally to test this, so it should finally pass ci
@arenasys
Copy link
Contributor

arenasys commented Mar 27, 2024

Currently need to install packages individually to get around this, this PR would make wrapping pip alot more efficient.

Copy link
Member

@ichard26 ichard26 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks and works great!

Yes, this doesn't have tests, but I'll note that #12586 which preceded this PR also didn't have tests.

@@ -0,0 +1 @@
Output install progress when 'raw' progress_bar type is in use
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Output install progress when 'raw' progress_bar type is in use
Output machine readable install progress when "raw" ``--progress-bar`` is enabled.

Comment on lines +120 to +123
if bar_type == "raw":
return functools.partial[Iterator[Tuple[str, InstallRequirement]]](
_raw_progress_bar, size=total, unit_size=1
)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried dropping the functools.partial type parameter here and in get_download_progress_renderer() and mypy was fine with it? Although, I'm not sure whether it affects inference or not.

@ichard26 ichard26 added this to the 24.3 milestone Jul 16, 2024
@tyler-suard-parker
Copy link

@joeyballentine are you able to click the "Merge pull request" button?

@joeyballentine
Copy link
Author

I am not

@tyler-suard-parker
Copy link

@ichard26 It looks like this PR was approved but never merged. Are you able to merge it?

@ichard26
Copy link
Member

I cannot, no. I don't have the commit bit on this project.

@sbidoul
Copy link
Member

sbidoul commented Oct 12, 2024

Hi,

As I understand this is meant to provide machine readable output, this should really have tests, otherwise there is no guarantee at all that the behaviour will be preserved over time.

OTOH, I'm not sure if pip did ever provide any guarantee about stability of it's logging output, and if we should encourage such use cases which would make it harder and harder to improve the logging output.

For instance, one simple thing that I've wanted to do, but refrained out of fear of breaking downstream tools, is send all logging output to stderr and keep human or machine readable output only on stdout.

So maybe we should clarify our stance about this topic before going further down that road?

@ichard26
Copy link
Member

So maybe we should clarify our stance about this topic before going further down [this] road?

I agree generally. Not something I'm interested in doing at the moment though. Removing this from the milestone.

@ichard26 ichard26 removed this from the 24.3 milestone Oct 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants