Use builtin mock

[JordonPhillips]

This removes the dependency on the mock package since it's built in to the python versions we support.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[codecov-commenter]

Codecov Report

All modified lines are covered by tests ✅

Comparison is base (8e05d3c) 93.13% compared to head (3201d4e) 93.15%.
Report is 1 commits behind head on v2.

Additional details and impacted files

@@            Coverage Diff             @@
##               v2    #8221      +/-   ##
==========================================
+ Coverage   93.13%   93.15%   +0.01%     
==========================================
  Files         364      364              
  Lines       38482    38482              
  Branches     6167     6167              
==========================================
+ Hits        35842    35847       +5     
+ Misses       1968     1963       -5     
  Partials      672      672              

see 3 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[nateprewitt]

I have no idea if this (ff59615) still ports forward (unlikely after 2 years) but we may want to do something closer to CLI v1 to keep the codebases as close as we can.

[yan12125]

I have no idea if this (ff59615) still ports forward (unlikely after 2 years) but we may want to do something closer to CLI v1 to keep the codebases as close as we can.

How about pushing similar changes for both v1 and v2 branches? unittest.mock is available since Python 3.3 [1], and aws-cli v1 already requires Python 3.7 [2].

[1] https://docs.python.org/3/library/unittest.mock.html
[2] https://github.com/aws/aws-cli/blob/develop/setup.py

[nateprewitt]

Thanks for the suggestion, @yan12125. That's what we currently do in CLI v1. I think the proposal was to move that functionality into the CLI v2 instead of doing a different implementation. I have a port of the above commit here that we may be able to use (f255378). Botocore will need it's changes too though.

[yan12125]

Thanks for the explanation and sorry for misunderstanding the intention. Your proposal is definitely a good move.

For botocore, porting boto/botocore@f22b2cd may be enough.

[yan12125]

For botocore, porting boto/botocore@f22b2cd may be enough.

I gave it a try, but I didn't go far as upstream botocore and bundled botocore v2 are quite different. As bundled botocore already deviates from upstream, how about doing a simple replacement for bundled botocore like this pull request, and using f255378 for the remaining?

By the way, this pull request can no longer be merged as-is due to conflicts.