Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upcore-admin(-client): --quiet & --verbose broken #3357
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment
Hide comment
jpouellet
Nov 30, 2017
Contributor
Well, it does still compute a single verbosity integer, but only privately for use in e.g. setting logging levels, not in the returned namespace - which makes me question if perhaps now tools are expected to handle checking a quiet property themselves?
|
Well, it does still compute a single verbosity integer, but only privately for use in e.g. setting logging levels, not in the returned namespace - which makes me question if perhaps now tools are expected to handle checking a |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment
Hide comment
|
/cc @woju |
andrewdavidwong
added
bug
C: core
labels
Nov 30, 2017
andrewdavidwong
added this to the Release 4.0 milestone
Nov 30, 2017
andrewdavidwong
modified the milestones:
Release 4.0,
Release 4.0 updates
Mar 31, 2018
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
jpouellet commentedNov 30, 2017
As best I can tell, the intended behavior is for objects returned by
qubes(admin).tools.QubesArgumentParser.parse_args()to only have averboseinteger property (defaulting to 1, incremented by --verbose, decremented by --quiet), and for consumers of the API to just compare against the value of theverboseproperty, as if aquietproperty did not exist.This seems to be the way things worked until around QubesOS/qubes-core-admin@015b01f when some refactoring stopped computing the single verbosity integer by default, leading to
--quietfor most qvm-* tools having no effect.Also, there is a bunch of code duplication between qubes and qubesadmin, with slight divergences, and I'd have to fix this in both. Is there a reason to want to maintain both separately? Or should some parts (e.g. the
qubes(admin).toolsutility module) first be factored out and the code deduplicated?