[Yum-devel] [RFC] python-urlgrabber progress patch

[James Antill]

 I've done a smallish patch to the progress bars in urlgrabber, they
help a couple of problems I've seen:

1. Long filenames can't be read, even after they've downloaded.
2. It's not easy to see your "average download speed".
3. Add hours in, because large numbers of minutes suck.
4. For download times of less than a minute the extra "00:" just
clutters up the view (dito. less than an hour).

...now I've currently got it split into two versions, one which
sacrifices some of #1 but gives #2 and one which does. And I added some
test functions if you run the progress module, so you can see it in
action. So first, this tries to do "solve" all four of the above:

(1/10): sm-1.0.0-1.fc8.i386.rpm               |   90 B/s | 1.0 kB       11     
(2/10): s-1.0.1-1.fc8.i386.rpm                |  163 B/s | 9.8 kB    01:01     
(3/10): m-1.0.1-2.fc8.i386.rpm                | 1.1 kB/s | 9.8 kB       08     
(4/10): large-file-name-Foo-11.8.7-4.5.6.1.fc | 9.4 kB/s | 977 kB    01:43     
(5/10): large-file-name-Foo2-11.8.7-4.5.6.2.f |  49 kB/s | 977 kB       20     
(6/10): large-file-name-Foo3-11.8.7-4.5.6.3.f | 391 kB/s | 977 kB       02     
(7/10): large-file-name-Foo4-10.8.7-4.5.6.1.f | 1.0 kB/s | 9.8 kB       10     
(8/10): large-file-name-Foo5-10.8.7-4.5.6.2.f | 2.0 kB/s | 9.8 kB       05     
(9/10): large-file-name-Foo6-10.8.7-4.5.6.3.f | 3.9 kB/s | 9.8 kB       02     
(10/10): large-file-name-   0% |              |   20 B/s | 8.0 kB 13:46:31 ETA 

...and here's the one that doesn't show the B/s data in current or done
downloads (but still has the minute/blank changes):

(1/10): sm-1.0.0-1.fc8.i386.rpm                          | 1.0 kB       11     
(2/10): s-1.0.1-1.fc8.i386.rpm                           | 9.8 kB    01:01     
(3/10): m-1.0.1-2.fc8.i386.rpm                           | 9.8 kB       08     
(4/10): large-file-name-Foo-11.8.7-4.5.6.1.fc8.x86_64.rp | 977 kB    01:43     
(5/10): large-file-name-Foo2-11.8.7-4.5.6.2.fc8.x86_64.r | 977 kB       20     
(6/10): large-file-name-Foo3-11.8.7-4.5.6.3.fc8.x86_64.r | 977 kB       02     
(7/10): large-file-name-Foo4-10.8.7-4.5.6.1.fc8.x86_64.r | 9.8 kB       10     
(8/10): large-file-name-Foo5-10.8.7-4.5.6.2.fc8.x86_64.r | 9.8 kB       05     
(9/10): large-file-name-Foo6-10.8.7-4.5.6.3.fc8.x86_64.r | 9.8 kB       02     
(10/10): large-file-name-   0% |                         |  380 B 13:34:48 ETA 

...so what does everyone think?

. I assume noone cares about dropping the dead space from the bar and
percentage?

. What about including the B/s, is that worth killing 11 bytes from the
name and/or bar?
  They are separate, so we could just do it in one or the other (they
are also slightly different, in the update() it is the rolling average
in end() it is the full B/s for the file).

. What about dropping the minutes when they are "00:"?

. What about including the hours when the minutes are >=60? If yes, I
assume we want to drop the hours when they are == "00:"?

...the patch, against current urlgrabber CVS, is attached and available
from:

 http://people.redhat.com/jantill/python/urlgrabber.patch


-- 
James Antill <james.antill at redhat.com>
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: urlgrabber.patch
Type: text/x-patch
Size: 5530 bytes
Desc: not available
Url : http://lists.baseurl.org/pipermail/yum-devel/attachments/20080129/731ce87b/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.baseurl.org/pipermail/yum-devel/attachments/20080129/731ce87b/attachment.pgp