Skip to content
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 no progress result printer to s3 transfer #2747

Merged
merged 5 commits into from
Oct 13, 2017
Merged

Conversation

joguSD
Copy link
Contributor

@joguSD joguSD commented Aug 3, 2017

This seemed relatively easy to implement and a lot of people have been asking for it.
This is basically a copy paste of the OnlyShowErrorsResultPrinter except that it still prints success messages. Just like the --only-show-errors flag you can now also pass --no-progress to omit the progress rendering. Not sure if I hit all the tests we need for this.

Implements: #519

Copy link
Member

@jamesls jamesls left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Had some small feedback.

@@ -369,6 +369,11 @@
'output is suppressed.')}


NO_PROGRESS = {'name': 'no-progress', 'action': 'store_true',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The no-* params typically have a store_false action with the destination being the param without the no prefix (progress in this case). Also makes it less confusing if we ever add an explicit true version of this arg (--progress).

@@ -369,6 +369,11 @@
'output is suppressed.')}


NO_PROGRESS = {'name': 'no-progress', 'action': 'store_true',
'help_text': (
'File transfer progress is not displayed.')}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's probably worth documenting that this arg only matter is the other two options aren't provided (quiet/only_show_errors)

@jamesls jamesls added changes-requested and removed pr:needs-review This PR needs a review from a Member. labels Sep 19, 2017
@codecov-io
Copy link

codecov-io commented Sep 21, 2017

Codecov Report

Merging #2747 into develop will increase coverage by <.01%.
The diff coverage is 100%.

Impacted file tree graph

@@             Coverage Diff             @@
##           develop    #2747      +/-   ##
===========================================
+ Coverage    95.58%   95.59%   +<.01%     
===========================================
  Files          151      151              
  Lines        11848    11860      +12     
===========================================
+ Hits         11325    11337      +12     
  Misses         523      523
Impacted Files Coverage Δ
awscli/customizations/s3/results.py 98.55% <100%> (+0.01%) ⬆️
awscli/customizations/s3/subcommands.py 97.16% <100%> (ø) ⬆️
awscli/customizations/s3/s3handler.py 97.79% <100%> (+0.02%) ⬆️
awscli/customizations/preview.py 100% <0%> (ø) ⬆️
awscli/customizations/cloudformation/deploy.py 100% <0%> (ø) ⬆️
awscli/clidocs.py 98.35% <0%> (ø) ⬆️
awscli/customizations/argrename.py 100% <0%> (ø) ⬆️
awscli/customizations/cloudformation/deployer.py 96.29% <0%> (+0.24%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7cd785b...cf8c3f3. Read the comment docs.

@joguSD joguSD added pr:needs-review This PR needs a review from a Member. and removed changes-requested labels Sep 21, 2017
Copy link

@c0reysc0tt c0reysc0tt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really hope this gets merged into an upcoming version soon. I manually made these changes to the three python files affected, and now the log files created by all my s3 cron scripts are useful and readable. As far as I can tell, it's a complete fix to a problem people have been complaining about for years. The --no progress option is documented in the help files the same as any other function and does what it says it does. Thank you joguSD!

Copy link
Contributor

@kyleknap kyleknap left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. I just had some very small comments. Also make sure you run the integration tests to make sure nothing is broken.

@@ -369,6 +369,15 @@
'output is suppressed.')}


NO_PROGRESS = {'name': 'no-progress',
'action': 'store_false',
'dest': 'progress',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure it is needed but all of the parameters like this have a 'default': True in the dictionary. Not sure if it is needed. Do not think it is. But it would not hurt to be consistent.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The other two flags like this don't have a default either, I think it's fine to have no default.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was referring to all of the boolean flags that have store_false as the action. I just checked the docs and did it on the command line and its fine. Putting the default kwarg whose value is True is redundant.

'dest': 'progress',
'help_text': (
'File transfer progress is not displayed. This flag '
'is only applied when the quiet and only-show-errors '
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the second sentence even matter? Based on the --quiet and --only-show-errors documentation, it will not show progress anyways. I would prefer to remove it in case we do not cause any confusion in the future if we add a new output parameter and forget to update this documentation.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The second sentence was added in response to some of James' feedback.

Copy link
Contributor

@kyleknap kyleknap Oct 12, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh its because it is conflicting. Like if --no-progress --quiet is provided which one would win? Yeah I'm fine with keeping it as is.

# Copy file into bucket.
p = aws('s3 cp %s s3://%s/ --no-progress' % (foo_txt, bucket_name))
self.assertEqual(p.rc, 0)
# Ensure success message was printed
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be good to assert there was no progress statement as well in the standard output.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated.

Copy link
Contributor

@kyleknap kyleknap left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. 🚢

@joguSD joguSD merged commit 2006dc0 into aws:develop Oct 13, 2017
@diehlaws diehlaws added feature-request A feature should be added or improved. and removed enhancement labels Jan 4, 2019
@justnance justnance added enhancement and removed feature-request A feature should be added or improved. labels Apr 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement medium pr:needs-review This PR needs a review from a Member.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants