I should add that the primary motivation here is to help us reduce the dependency set (and thus the maintenance cost and installation size) of rpmdevtools in Fedora ELN (the upcoming RHEL-9), where it currently is the only package pulling in progressbar2 (and its dependency python-utils).

This is starting to cross the point at which I'm getting uncomfortable with shoving everything into once script file, and it also doesn't benefit from bytecode compilation at all this way. Additionally the class constructors look like python 2 style, you do not need to inherit from object anymore.

I'm starting to ask myself a different question: Do we actually need a progress bar for downloads? The one from progressbar2 is nice, but showing a progress bar also has problems (e.g. when the server does not provide content-length header, or when RPM is messing with the process's timezone again ...)

This is starting to cross the point at which I'm getting uncomfortable with shoving everything into once script file, and it also doesn't benefit from bytecode compilation at all this way.

Agreed - we could split it into a separate "utils.py" file of some sort, but that would have to be installed in the python library path (currently we don't install anything there). But no big deal, could be done.

Additionally the class constructors look like python 2 style, you do not need to inherit from object anymore.

Thanks for spotting that, will fix :)

I'm starting to ask myself a different question: Do we actually need a progress bar for downloads?

Yeah, I asked myself the same, but then, some tarballs are pretty big, so at least some feedback is probably more user-friendly than nothing. At which point, showing an actual "bar" is not much additional work...

The one from progressbar2 is nice, but showing a progress bar also has problems (e.g. when the server does not provide content-length header, or when RPM is messing with the process's timezone again ...)

When there's no content-length header, it shows a "spinner" with the downloaded size so far, which is also what the implementation in this PR does.

That being said, I'm totally fine with us deciding not to merge this. There certainly are downsides to implementing everything ourselves, obviously. Either way, it's been a good little programming exercise for me :)

I'm also thinking that, with this being predominantly a RHEL-specific change, perhaps we should just ship this (as a separate python module, as you suggested) in the downstream rpmdevtools package in RHEL, as opposed to forcing this upon Fedora where it has little value (as progressbar2 already is present there).

Considering progressbar2 is useful for a number of projects, is it really that bad to ship it in RHEL?

It's not bad at all, it's just that rpmdevtools is currently the only user of it (in ELN/RHEL), so it seems like an overkill to maintain there (and support) an additional general-purpose package just for that.

It would definitely be great if everyone agreed on a single python library for progress bars, but that's not the case, sadly. In reality, most python packages seem to implement their own thing (our team is guilty of it too, see YUM/DNF). Another such library seems to be tqdm, which is also used by a couple of packages in Fedora, but that's still just a handful.

So yeah, truth be told, this is just to scratch our own itch in RHEL we're having right now, and it can be solved in other ways too (just shipping progressbar2 being one of them) :)

Funny thing is, as I was writing the above, I realized I just made a full circle :D On one hand we're complaining that everyone is making these progressbars on their own, on the other hand, not shipping a well-maintained implementation (be it progressbar2 or something else) won't help change that :D

Anyway, it seems like the general consensus here is biased towards closing this, and I'm fine with that :) We'll consider this patch in RHEL (for the time being at least), but I agree that otherwise there really is not much value in it (progressbar2 is not some humongous library where we would worry about its installation size in e.g. containers, after all).

Indeed. I think I'm going to close this, then.