Pin package versions in Setup.py

[Pascal-0x90]

Touching on an issue brought up in #54 .

🗣 Description

For each package, updated the setup.py file to pin each package to a minimum requirement if
not a definite requirement.

💭 Motivation and context

To keep the versions of packages installed when setting up development, testing, and production
environments consistent and working with the tool. Ref #54 .

🧪 Testing

Reinstalled environment and ran tool tests with success.

✅ Pre-approval checklist

• This PR has an informative and human-readable title.
• Changes are limited to a single goal - eschew scope creep!
• All future TODOs are captured in issues, which are referenced
  in code comments.
• All relevant type-of-change labels have been added.
• I have read the CONTRIBUTING document.
• These code changes follow cisagov code standards.
• All relevant repo and/or project documentation has been updated
  to reflect the changes in this PR.
• Tests have been added and/or modified to cover the changes in this PR.
• All new and existing tests pass.

✅ Pre-merge checklist

• Revert dependencies to default branches.
• Finalize version.

✅ Post-merge checklist

• Add a tag or create a release.

[mcdonnnj]

Please do not pin to a specific version unless absolutely necessary. If you do need to pin to a specific version then please include documentation for why. Pins in our Python packages should try to be as loose as possible within compatibility constraints.

[Pascal-0x90]

Please do not pin to a specific version unless absolutely necessary. If you do need to pin to a specific version then please include documentation for why. Pins in our Python packages should try to be as loose as possible within compatibility constraints.

Roger that @mcdonnnj ! Would a minimum version be acceptable at least? I was trying to pin the ones using request APIs like dnspython, ipwhois, and urllib3 just because I would worry the api for those could change (dnspython already is trying to deprecate the query API). Though if you think those are safe I would trust you more on those and I can just make the specific version pins all >= since the current version is acceptable.

There does seem to be an issue with Python 3.6 but I think that might just be a runner issue not specifically a code issue. Correct me if I am wrong though.

[mcdonnnj]

Please do not pin to a specific version unless absolutely necessary. If you do need to pin to a specific version then please include documentation for why. Pins in our Python packages should try to be as loose as possible within compatibility constraints.

Roger that @mcdonnnj ! Would a minimum version be acceptable at least? I was trying to pin the ones using request APIs like dnspython, ipwhois, and urllib3 just because I would worry the api for those could change (dnspython already is trying to deprecate the query API). Though if you think those are safe I would trust you more on those and I can just make the specific version pins all >= since the current version is acceptable.

There does seem to be an issue with Python 3.6 but I think that might just be a runner issue not specifically a code issue. Correct me if I am wrong though.

@Pascal-0x90 Minimum and maximum bounds such as >=1,<2 are completely fine, The only thing to avoid if possible is pinning to a specific version. If you must pin to a specific version that's fine but the reason should be documented.

Python 3.6 is failing because there is no file available for Ubuntu 22.04 runners (new default for ubuntu-latest). It is theoretically being worked on and we were looking at dropping support for 3.6 since it is EOL anyway. We could always pin the runners in the matrix so that 3.6 runs against a ubuntu-20.04 runner and everything else uses ubuntu-latest.