Refine CLI for use with get_table as almanack <repo path>

[d33bs]

Description

This PR refines the CLI to use get_table as $ almanack <repo path> when the Software Gardening Almanack is used through python-fire. The goal was to make using the internal functionality easily from outside of a Pythonic API, for example, as with workflow pipelines that may not use Python API's.

Thanks for any feedback!

Closes #134

What is the nature of your change?

• Content additions or updates (adds or updates content)
• Bug fix (fixes an issue).
• Enhancement (adds functionality).
• Breaking change (these changes would cause existing functionality to not work as expected).

Checklist

Please ensure that all boxes are checked before indicating that this pull request is ready for review.

• I have read the CONTRIBUTING.md guidelines.
• My code follows the style guidelines of this project.
• I have performed a self-review of my own contributions.
• I have commented my content, particularly in hard-to-understand areas.
• I have made corresponding changes to related documentation (outside of book content).
• My changes generate no new warnings.
• New and existing tests pass locally with my changes.
• I have added tests that prove my additions are effective or that my feature works.
• I have deleted all non-relevant text in this pull request template.

[falquaddoomi]

Nice work; seems like you cleaned up a lot of things and added some tests. I made a few comments which probably should be reviewed before merging, but nothing serious.

[d33bs]

Thanks @falquaddoomi for the review! I've made some changes based on your comments and revisited what @gwaybio mentioned, regarding the unsafe space splitting for the subprocess testing utility function, based on both of your feedback.

[d33bs]

Openly, I wondered if the default behavior of the output returned by almanack <repo path> should be a human-readable table instead of data. We could add a --json flag to return what is currently provided. Perhaps this is an additional issue/ PR at a later time?

[falquaddoomi]

Openly, I wondered if the default behavior of the output returned by almanack <repo path> should be a human-readable table instead of data. We could add a --json flag to return what is currently provided. Perhaps this is an additional issue/ PR at a later time?

I think that sounds like a reasonable idea, if you expect people to be using it interactively rather than parsing it. I think it pertains to this PR so it would make sense to include it here, but it's up to you if you'd prefer for it to be reviewed in more detail in a different PR.

[d33bs]

Thanks @falquaddoomi - I created #172 to further this development. I don't know of an exact demand for this right now whereas we can more readily make use of this PR's CLI modifications as is.

Separately, @gwaybio , @falquaddoomi , is there anything else I may add to this PR in order to ready it for a merge? Thanks in advance for any further feedback!

[falquaddoomi]

I don't have anything to add; this all looks good to me!

[d33bs]

Thanks @falquaddoomi and @gwaybio for your reviews! Merging this in now.