Add versioning capabilities

[d33bs]

Description

This PR adds versioning capabilities for this project to help distinguish between different versions. Here's a story to help contextualize these changes: "As a person using SCulptQC I need to know what version of the software I'm using to help with package management and troubleshooting when necessary." Using poetry-dynamic-versioning helps ensure any installation of the package is described by a "dynamic version", one which takes into consideration semantic version git tags as well as commit hashes beyond a version tag.

I've added a tag for v0.0.1 to help indicate this initial version we're working towards. Later versions I feel might be best specified through GitHub Releases work in #6 . I also added a poetry-check to help avoid issues with the lockfile being out of alignment.

Thanks for any thoughts and feedback you may have!

Closes #5

What kind of change(s) are included?

• Feature (adds or updates new capabilities)
• 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 and followed the CONTRIBUTING.md guidelines.
• I have searched for existing content to ensure this is not a duplicate.
• I have performed a self-review of these additions (including spelling, grammar, and related).
• These changes pass all pre-commit checks.
• I have added comments to my code to help provide understanding
• I have added a test which covers the code changes found within this PR
• I have deleted all non-relevant text in this pull request template.

[jenna-tomkinson]

LGTM! It makes sense to include this and I like that it looks to be pretty simple. Feel free to merge!

I do have one question now that I think of it, is there a need to include a test for this? I see it isn't checked off in the original comment for the PR.

[d33bs]

Thanks @jenna-tomkinson !

I do have one question now that I think of it, is there a need to include a test for this? I see it isn't checked off in the original comment for the PR.

I like your test-driven thinking here! I'm inclined to say "yes" and created #9 as a result. I'm cautious to add a test yet for this now as things may change and versioning might be something tested alongside releases and deployments. I also think it may involve somewhat complex testing outside of pytest. The pseudocode for testing something like this could look like:

1. Checkout code from GitHub Actions job
2. Add arbitrary commit within the context of the GitHub Actions job checked-out code
3. Run poetry build
4. Examine the results of the build __init__.py file for an accurate version specification
5. Attempt to install the built package and observe the same version as previous step

[d33bs]

Note: after this PR was merged I found the tag was dropped. I've manually applied this post-merge using the git CLI.