New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add human-readable sizes option #48
Conversation
Hah. Totally missed that |
…erence from both repoutil and repo_sync
else: | ||
return str(cast_unit(round(size_in_bytes/float(limit/2**10), 1))) + suffix | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hope nobody is parsing output and relying on the old output format for anything... If the reason for adding a 'HumanReadableSizes' preference was to prevent changing the output format without admin consent, that's pointless with the other changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think if you feel strongly about "KiB/MiB/etc", your might consider ditching the 'HumanReadableSizes' preference and just always use human-readable sizes, since the output format is going to change either way.
In any case, if the output format is going to change, it would be best to bring the topic up for discussion on the reposado mailing list.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Few things: 1) HumanReadableSizes needs to be explicitly set in your preferences else you get the previous behavior. This means that the only "change" with the KiB/MiB, etc. is in the repoutil --info
output. I'm not sure how many folks would be parsing info
output. 2) I really don't feel strongly about it. I actually figured you'd comment on that part :), so that whole commit can be reversed if you want. 3) If that commit were reversed would you be averse to changing the units to proper SI units (multiples of 1000) vs. binary prefixes? Output format wouldn't change, but the numbers would, slightly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't feel strongly about any of this.
Obligatory xkcd: https://xkcd.com/1172/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mostly wanted #16 to go away. 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whereas open issues don't bother me in the least. (unless they affect me)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, I reverted the base and now use SI units (in the same format as before). Yay or nay? 😄
@@ -92,6 +92,17 @@ The following keys are optional and may be defined in preferences.plist for spec | |||
|
|||
Defaults to no log file. | |||
|
|||
- HumanReadableSizes | |||
|
|||
Enable human-readable file sizes in download messages e.g. KiB, MiB. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Docs don't match current code implementation...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, indeed.
Implements #16