[Bug 1648728] New: Review Request: python-progressbar2 - A Progressbar library to provide visual progress to long running operations
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
Bug ID: 1648728 Summary: Review Request: python-progressbar2 - A Progressbar library to provide visual progress to long running operations Product: Fedora Version: rawhide Component: Package Review Severity: medium Priority: medium Assignee: nobody@fedoraproject.org Reporter: sanjay.ankur@gmail.com QA Contact: extras-qa@fedoraproject.org CC: package-review@lists.fedoraproject.org
Spec URL: https://ankursinha.fedorapeople.org/python-progressbar2/python-progressbar2.... SRPM URL: https://ankursinha.fedorapeople.org/python-progressbar2/python-progressbar2-...
Description: A text progress bar is typically used to display the progress of a long running operation, providing a visual cue that processing is underway.
The ProgressBar class manages the current progress, and the format of the line is given by a number of widgets. A widget is an object that may display differently depending on the state of the progress bar. There are many types of widgets:
- AbsoluteETA - AdaptiveETA - AdaptiveTransferSpeed - AnimatedMarker - Bar - BouncingBar - Counter - CurrentTime - DataSize - DynamicMessage - ETA - FileTransferSpeed - FormatCustomText - FormatLabel - Percentage - ReverseBar - RotatingMarker - SimpleProgress - Timer
The progressbar module is very easy to use, yet very powerful. It will also automatically enable features like auto-resizing when the system supports it.}
Fedora Account System Username: ankursinha
Rawhide scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=30812638 F29 scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=30812833
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
Ankur Sinha (FranciscoD) sanjay.ankur@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |1276941 (fedora-neuro) Alias| |python-progressbar2
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1276941 [Bug 1276941] Fedora NeuroImaging and NeuroScience tracking bug
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED CC| |zbyszek@in.waw.pl Assignee|nobody@fedoraproject.org |zbyszek@in.waw.pl
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |POST Flags| |fedora-review+
--- Comment #1 from Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl ---
PR filed
An URL would be nice.
find . -name "*.pyc" -exec rm -fv '{}' ;
find . -name '*.pyc' -print -delete
I think that the list of widgets in the description could be removed. It's not necessary to the users of the package.
+ package name is OK + latest version + builds and installs OK + license is acceptable for Fedora (BSD) + license is specified correctly + fedora-review is happy (there's a lot of spam from rpmlint, but I think it's all bogus).
Package is APPROVED.
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
--- Comment #2 from Ankur Sinha (FranciscoD) sanjay.ankur@gmail.com --- Thanks for the review, Zbigniew. I've updated the spec accordingly.
I'm worried that this conflicts with the python-progressbar package:
sudo dnf whatprovides '/usr/lib/python3.7/site-packages/progressbar' Last metadata expiration check: 2:00:11 ago on Mon 12 Nov 2018 18:21:35 GMT. python3-progressbar-2.3-13.20170808git32422c1.fc29.noarch : Text progressbar library for Python 3 Repo : fedora Matched from: Filename : /usr/lib/python3.7/site-packages/progressbar
I reckon that means we can't have both packages without some hacking here?
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
Ankur Sinha (FranciscoD) sanjay.ankur@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugzilla.redhat.com | |/show_bug.cgi?id=1218533
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|POST |ASSIGNED Flags|fedora-review+ |fedora-review?
--- Comment #3 from Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl --- Yeah, I didn't check this. This needs to be figured out somehow.
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
--- Comment #4 from Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl --- Is this progressbar package incompatible with the other one? If yes, then I think the best option would be to rename the module in this one to progressbar2. The imports in users would have to be adjusted to match. But this would be a simple 'sed -i' in %prep, so not too cumbersome.
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pviktori@redhat.com Flags| |needinfo?(pviktori@redhat.c | |om)
--- Comment #5 from Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl --- It seems that both this progressbar (https://github.com/WoLpH/python-progressbar) and the other progressbar (https://github.com/niltonvolpato/python-progressbar) are maintained. The API look similar, so it is actually possible that dependent packages could be fine with either.
I think it'd be better to keep just one package, to avoid work, if they are compatible enough. Maintainers of python-progressbar, what do you think?
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |christof@damian.net Flags| |needinfo?(christof@damian.n | |et)
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tuanta@iwayvietnam.com Flags| |needinfo?(tuanta@iwayvietna | |m.com)
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
Petr Viktorin pviktori@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(pviktori@redhat.c | |om) | |needinfo?(christof@damian.n | |et) | |needinfo?(tuanta@iwayvietna | |m.com) |
--- Comment #6 from Petr Viktorin pviktori@redhat.com --- The choice of naming the library differently than the imported module is really unfortunate, especially if the author knew a "progressbar" library already exists. The two cannot be installed simultaneously.
Progressbar 2 looks more featureful and tested, but progressbar is used by other packages (and probably users) in Fedora, so we need to be careful.
Can you get upstreams of Fedora packages that currently need progressbar to switch to progressbar2? Those are euca2ools, libtaskotron and python-bitmath, AFAICS.
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
Petr Viktorin pviktori@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(christof@damian.n | |et)
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
Petr Viktorin pviktori@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(tuanta@iwayvietna | |m.com)
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
--- Comment #7 from Ankur Sinha (FranciscoD) sanjay.ankur@gmail.com --- I've asked progressbar2 upstream here: https://github.com/WoLpH/python-progressbar/issues/177
Hopefully progressbar2 will be compatible with the original and we wont have to make any downstream changes (or request upstreams to move etc.)
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
--- Comment #8 from Petr Viktorin pviktori@redhat.com --- I'm not worried about them being compatible *now*.
Consider this scenario: - We replace python-progressbar by progressbar2 in Fedora - The original progressbar adds a new feature, which is not in progressbar2 - python-bitmath upstream starts depending on the new feature
In this case, we couldn't update python-bitmath in Fedora.
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
--- Comment #9 from Ankur Sinha (FranciscoD) sanjay.ankur@gmail.com --- Sure, but in either case once we decide what upstream to follow, we'll have to request upstreams of whatever packages to switch to it.
Would it be possible to ask the python-progressbar upstream to retire it, and add a notice requesting people to move to the newer one, which appears to have more features and is better maintained?
If this cannot be sorted at an upstream level, the downstream resorts will be to make the two conflict, or we carry downstream patches for lots of software to make the two installable not conflict. (Neither of these are attractive to me).
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
--- Comment #10 from Petr Viktorin pviktori@redhat.com --- (In reply to Ankur Sinha (FranciscoD) from comment #9)
Sure, but in either case once we decide what upstream to follow, we'll have to request upstreams of whatever packages to switch to it.
Yes. If one is clearly better than the other, it shouldn't be an issue, right?
Would it be possible to ask the python-progressbar upstream to retire it, and add a notice requesting people to move to the newer one, which appears to have more features and is better maintained?
IMO it would be better to merge with the fork, since "progressbar" is clearly a better name than "progressbar2".
If this cannot be sorted at an upstream level, the downstream resorts will be to make the two conflict, or we carry downstream patches for lots of software to make the two installable not conflict. (Neither of these are attractive to me).
Exactly.
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
--- Comment #11 from Ankur Sinha (FranciscoD) sanjay.ankur@gmail.com --- (In reply to Petr Viktorin from comment #10)
(In reply to Ankur Sinha (FranciscoD) from comment #9)
Sure, but in either case once we decide what upstream to follow, we'll have to request upstreams of whatever packages to switch to it.
Yes. If one is clearly better than the other, it shouldn't be an issue, right?
I hope not, but one can't say with upstreams XD
Here's what progressbar2 upstream said:
https://github.com/WoLpH/python-progressbar/issues/177#issuecomment-43870601...
"Hi Ankur,
It seems the original module has gotten at least a bit of a revival, but I still see several issues going all the way back to 2010 (such as this one: niltonvolpato/python-progressbar#8 (comment)) so I'm inclined to say it's still not receiving all that much love.
Throughout the development I've always taken care to make the interface backwards compatible so it won't cause any issues for people that switch between the libraries. Since the original project didn't have any tests it's hard to know for certain, but I don't see any issues when running the original project examples.py script."
So:
- do we agree progressbar2 is more active and a better candidate?
- if we do, * should we use the progressbar2 upstream in Fedora's python-progressbar package:
** should we test to see if the packages that depend on the older version function properly with the new one without requiring any changes (that'd be awesome)? *** If they do, can we notify upstreams and request them to work against progressbar2 in the future? *** if they do not, can we request their upstreams to migrate? ** does this require some sort of change notification (or simply an e-mail to -devel)
Would it be possible to ask the python-progressbar upstream to retire it, and add a notice requesting people to move to the newer one, which appears to have more features and is better maintained?
IMO it would be better to merge with the fork, since "progressbar" is clearly a better name than "progressbar2".
This would be brilliant too---we could work on this once the aforementioned points are taken care of?
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
--- Comment #12 from Ankur Sinha (FranciscoD) sanjay.ankur@gmail.com --- Hello,
Any thoughts on this?
Cheers! Ankur
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
--- Comment #13 from Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl --- Somebody should test euca2ools, libtaskotron and python-bitmath with progressbar2 installed in place of progressbar. If that works, things should be quite easy.
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
Luis Bazan bazanluis20@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |1651388 (python-xnat)
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1651388 [Bug 1651388] python-xnat
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
--- Comment #14 from Ankur Sinha (FranciscoD) sanjay.ankur@gmail.com --- (In reply to Zbigniew Jędrzejewski-Szmek from comment #13)
Somebody should test euca2ools, libtaskotron and python-bitmath with progressbar2 installed in place of progressbar. If that works, things should be quite easy.
I ran some quick tests in a virtual environment.
--
I can't get libtaskotron's tests to run even with the original progressbar module. I don't know how these tests are meant to be run. I get this with both. Someone else will have to check that up:
running test Traceback (most recent call last): File "/usr/lib/python3.7/site-packages/_pytest/config/__init__.py", line 372, in _getconftestmodules return self._path2confmods[path] KeyError: local('/home/asinha/dump/progressbar-test/libtaskotron/testing')
During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.7/site-packages/_pytest/config/__init__.py", line 403, in _importconftest return self._conftestpath2mod[conftestpath] KeyError: local('/home/asinha/dump/progressbar-test/libtaskotron/testing/conftest.py')
During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.7/site-packages/_pytest/config/__init__.py", line 409, in _importconftest mod = conftestpath.pyimport() File "/usr/lib/python3.7/site-packages/py/_path/local.py", line 668, in pyimport __import__(modname) File "/usr/lib/python3.7/site-packages/_pytest/assertion/rewrite.py", line 226, in load_module py.builtin.exec_(co, mod.__dict__) File "/home/asinha/dump/progressbar-test/libtaskotron/testing/conftest.py", line 13, in <module> import libtaskotron.config File "/home/asinha/dump/progressbar-test/libtaskotron/libtaskotron/config.py", line 25, in <module> from libtaskotron import file_utils File "/home/asinha/dump/progressbar-test/libtaskotron/libtaskotron/file_utils.py", line 12, in <module> import progressbar ModuleNotFoundError: No module named 'progressbar' ERROR: could not load /home/asinha/dump/progressbar-test/libtaskotron/testing/conftest.py
--
bitmath looks like it needs patching:
.. running build_ext Traceback (most recent call last): File "setup.py", line 81, in <module> 'bitmath = bitmath:cli_script', File "/home/asinha/dump/progressbar2-virt/lib64/python3.7/site-packages/setuptools/__init__.py", line 140, in setup return distutils.core.setup(**attrs) File "/usr/lib64/python3.7/distutils/core.py", line 148, in setup dist.run_commands() File "/usr/lib64/python3.7/distutils/dist.py", line 966, in run_commands self.run_command(cmd) File "/usr/lib64/python3.7/distutils/dist.py", line 985, in run_command cmd_obj.run() File "/home/asinha/dump/progressbar2-virt/lib64/python3.7/site-packages/setuptools/command/test.py", line 228, in run self.run_tests() File "/home/asinha/dump/progressbar2-virt/lib64/python3.7/site-packages/setuptools/command/test.py", line 250, in run_tests exit=False, File "/usr/lib64/python3.7/unittest/main.py", line 100, in __init__ self.parseArgs(argv) File "/usr/lib64/python3.7/unittest/main.py", line 124, in parseArgs self._do_discovery(argv[2:]) File "/usr/lib64/python3.7/unittest/main.py", line 244, in _do_discovery self.createTests(from_discovery=True, Loader=Loader) File "/usr/lib64/python3.7/unittest/main.py", line 154, in createTests self.test = loader.discover(self.start, self.pattern, self.top) File "/usr/lib64/python3.7/unittest/loader.py", line 347, in discover tests = list(self._find_tests(start_dir, pattern)) File "/usr/lib64/python3.7/unittest/loader.py", line 404, in _find_tests full_path, pattern, namespace) File "/usr/lib64/python3.7/unittest/loader.py", line 481, in _find_test_path tests = self.loadTestsFromModule(package, pattern=pattern) File "/home/asinha/dump/progressbar2-virt/lib64/python3.7/site-packages/setuptools/command/test.py", line 54, in loadTestsFromModule tests.append(self.loadTestsFromName(submodule)) File "/usr/lib64/python3.7/unittest/loader.py", line 154, in loadTestsFromName module = __import__(module_name) File "/home/asinha/dump/progressbar-test/bitmath/bitmath/integrations.py", line 84, in <module> class BitmathFileTransferSpeed(progressbar.widgets.Widget): AttributeError: module 'progressbar.widgets' has no attribute 'Widget'
...
euca2ools isn't py3 compatible from the looks of it? Will it be dropped in rawhide then?
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
Luis Bazan bazanluis20@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks|1651388 (python-xnat) |
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1651388 [Bug 1651388] python-xnat
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
Luis Bazan bazanluis20@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |1651388 (python-xnat)
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1651388 [Bug 1651388] python-xnat
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
Luis Bazan bazanluis20@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks|1651388 (python-xnat) |
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1651388 [Bug 1651388] python-xnat
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
Luis Bazan bazanluis20@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |1651388 (python-xnat)
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1651388 [Bug 1651388] Review Request: python-xnat - A new XNAT client that exposes XNAT objects/functions as python objects/functions
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
--- Comment #15 from Ankur Sinha (FranciscoD) sanjay.ankur@gmail.com --- While all of this is sorted, can I package progressbar2 up as a separate pacakge and add conflicts: python-progressbar?
I'd like to have one implementation of progressbar, but I do not have the cycles to patch the 3 packages that use the older implementation. So, this is a shorter, temporary solution.
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
Ankur Sinha (FranciscoD) sanjay.ankur@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugzilla.redhat.com | |/show_bug.cgi?id=1654745
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
Ankur Sinha (FranciscoD) sanjay.ankur@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugzilla.redhat.com | |/show_bug.cgi?id=1654746
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
Ankur Sinha (FranciscoD) sanjay.ankur@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugzilla.redhat.com | |/show_bug.cgi?id=1654747
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
--- Comment #16 from Ankur Sinha (FranciscoD) sanjay.ankur@gmail.com --- I've filed bugs against the three packages requesting the maintainers to consider using progressbar2 also.
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
--- Comment #17 from Ankur Sinha (FranciscoD) sanjay.ankur@gmail.com --- (In reply to Ankur Sinha (FranciscoD) from comment #15)
While all of this is sorted, can I package progressbar2 up as a separate pacakge and add conflicts: python-progressbar?
I meant---since this package is good (comment 1, 2, 3), could the review be approved again and may I import it with the conflicts? (Sorry, not enough tea/coffee yet).
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
Ankur Sinha (FranciscoD) sanjay.ankur@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(pviktori@redhat.c | |om)
--- Comment #18 from Ankur Sinha (FranciscoD) sanjay.ankur@gmail.com --- - Libtaskotron maintainer is happy to consider migration once progressbar2 is in Fedora (https://bugzilla.redhat.com/show_bug.cgi?id=1654746#c1)
- python-bitmath upstream is also happy to migrate (https://bugzilla.redhat.com/show_bug.cgi?id=1654747#c1)
Petr, is this enough to make progressbar2 the default implementation, or should I import it as a different package based on this review?
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
--- Comment #19 from Ankur Sinha (FranciscoD) sanjay.ankur@gmail.com --- Ping progressbar maintainers: thoughts?
Zbigniew, could you please re-approve the package and let me import it? If the progressbar maintainers decide to use progressbar2 in the future, I can obsolete the package. This is holding up other packages that use progressbar2.
Cheers, Ankur
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
Petr Viktorin pviktori@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(christof@damian.n | |et) | |needinfo?(tuanta@iwayvietna | |m.com) | |needinfo?(pviktori@redhat.c | |om) |
--- Comment #20 from Petr Viktorin pviktori@redhat.com --- Hello, and apologies for the delay.
If the progressbar and progressbar2 upstreams diverge, we'll be in quite a tough spot. But for now, it seems progressbar2 is better maintained, and wants to keep compatibility with the original.
So, let's replace python3-progressbar by python3-progressbar2. The python2 package is going away soon though; let's keep that as it is.
Ankur, if it works for you, can you: - post a heads-up to Fedora-devel, CCing maintainers of the dependent packages and the other progressbar admins (tuanta, cdamian), saying what the plan is
- remove the python2-progressbar2 subpackage entirely from the spec (this should simplify it quite a bit!)
- make python3-progressbar2 replace python3-progressbar (using versioned Obsoletes & Provides)
- get it approved
- please, add me as a co-maintainer
- let me know so I can remove the python3-progressbar package
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
--- Comment #21 from Ankur Sinha (FranciscoD) sanjay.ankur@gmail.com --- Hi Petr,
That sounds good. I'll work on it when I get back from work this evening.
Thanks again, Ankur
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
--- Comment #22 from Ankur Sinha (FranciscoD) sanjay.ankur@gmail.com --- * Announced to devel list * FpGM requested a change request so I've done this now: https://fedoraproject.org/wiki/Changes/Python-progressbar2_as_default
Since we're changing the default, I *think* it's a system-wide change. I don't expect it to be an issue, though.
* Removed py2 * Obsolete python3-progressbar (I don't see any python-progressbar builds for f30?)
* Updated spec/srpm: https://ankursinha.fedorapeople.org/python-progressbar2/python-progressbar2.... https://ankursinha.fedorapeople.org/python-progressbar2/python-progressbar2-...
The tests won't yet run because freezegun needs an update. Noted in spec.
Cheers! Ankur
https://bugzilla.redhat.com/show_bug.cgi?id=1648728
Cătălin George Feștilă catalinfest@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |catalinfest@gmail.com
--- Comment #23 from Cătălin George Feștilă catalinfest@gmail.com --- I think will need to go on to python 3.x version I agree with python3-progressbar features.
package-review@lists.fedoraproject.org
-
bugzilla＠redhat.com