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

feat: show progress messages on initialization, for reassurance #41

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

wally-crunk
Copy link

@wally-crunk wally-crunk commented Jan 16, 2025

When starting up, thousands of files can take a long time to read, and there's no screen output.

Suggested: a welcome message and progress indicator, so user knows the program started successfully and not hung on start.

@zakkarry
Copy link
Collaborator

I might be able to help with this, I recently was playing around with progress bars using the rich module.

Perhaps an indexing progress bar would give the feedback you were looking for?

If so, I will speak to @moleculekayak about any implementation details he might have in mind.

Comment on lines +149 to +150
print(f"\rStarting up. Collecting infohashes...")
print(f"\rFound {len(files)} files to process...")
Copy link
Owner

Choose a reason for hiding this comment

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

Just for my curiosity, what's the purpose of the carriage returns at the start of the lines? Since print includes a newline, shouldn't the carriage return be unneeded?

Copy link
Author

Choose a reason for hiding this comment

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

You are right, the only \r that is truly needed is the one in print(f"\r({processed}/{len(files)})…
because it is trying to overwrite the current output line.

@moleculekayak
Copy link
Owner

@zakkarry honestly, I'm okay with this approach. It's simple and doesn't include any addl. deps. Thoughts?

@zakkarry
Copy link
Collaborator

@zakkarry honestly, I'm okay with this approach. It's simple and doesn't include any addl. deps. Thoughts?

If keeping the dep surface down is a desire, than I agree. I will say that my main reason for bringing it up is that I recently used them and not much more.

The amount of effort in getting the callback and displaying of the bars consistent with something like rich or progress is pretty incongruent with the benefits it provides being brief, aesthetic, and not much more.

Perhaps just a timer, though, to signify that it isn't frozen? Then when complete you can see how long the processing took at least and know that it did not freeze.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants