show status updates during long bughelper runs

Thanks for your bug report. The progress bar should be easy to implement, after the BugList() has been initialized. For the utilized bandwidth, I'm not sure if we should have that and how to implement it.

Maybe have a command line switch to turn this functionality off. It will make no sense in logfiles, reports, etc.

Hi Andrew,
I think adding a progress bar to show the download status of a file might be the easiest solution. This (huge) patch against python-launchpad-bugs/main r9 adds the progress bar module written by Nilton Volpato to this branch. I used this module to show the download process of each file.

Markus

Oh, I forgot the url of that module:
[http://cheeseshop.python.org/pypi/progressbar/2.2]

The patch in launchpadBugs/HTMLOperations.py is simple enough - nice work.

Some reservations I personally have:
 - shipping external code in lpbugs - I'm not extremely fond of it. I'd much prefer to ship it in a separate package where it gets updated regularly, etc.
 - verbose=True - I'd rather this was False - tools/scripts (which might pipe the output somewhere else) should have to enable it
 - my gut feeling is, that the output is too verbose - can we change this somehow so that the percentage of visited bugs is reflected in the progressbar and not every attachment?

If we package python-progressbar, it'd need to be reviewed for main inclusion, as python-launchpad-bugs would depend on it. I don't know if that's at all possible, but could we have it as a dependency of bughelper? (it doesn't feel so much python-lp-bugs related to me).

Glad Markus' patch looks clean.

Showing how far bughelper's total operation has progressed would be fine for me, rather than each attachment.

Maybe the progress bar could show overall progress on commands that deal with multiple bugs in a % of bugs completed form, and then on commands dealing with only one bug report show progress as a % of total bytes downloaded that will need to be in the attachments. If that's too much for this first run at the progress bar, I'm fine with it. Maybe a future release could incorporate some of these ideas too.

The verbosity I was planning on was for more of an end-user that's using bughelper straight from the command line in the form of the progress bar. That bar only serves as a notification to users of how far that run has progressed, and obviously wouldn't mean much to those looking at output of scripts like the one on your site, Daniel. My gut feeling is that the progress bar should be enabled by default for those that use bughelper manually, but with an option to disable it for output to scripts. Notification of progress is best suited to users manually using the tool, which I feel is the majority currently, so it should be enabled by default.

Notice of exactly what files from what bugs were downloaded when wasn't really in the scope of what I had originally proposed in the progress bar, and I don't really see a need for it. I was just wanting to see a display of progress as I was waiting for the run to finish.