Utilize GH Workflow to publish to PyPI

[ibnesayeed]

This implements the last point of #630. Also, related to #649.

[codecov]

Codecov Report

Merging #654 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #654   +/-   ##
=======================================
  Coverage   27.28%   27.28%           
=======================================
  Files           7        7           
  Lines        1246     1246           
  Branches      191      191           
=======================================
  Hits          340      340           
  Misses        881      881           
  Partials       25       25           

---

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 43936d2...f4fe811. Read the comment docs.

[machawk1]

@ibnesayeed Will this keep the releases on GitHub and pypi in step?

[ibnesayeed]

Will this keep the releases on GitHub and pypi in step?

Releases on GH will be performed the same way as before (i.e., by running release.sh file locally). Installing twine, packaging, and publishing to PyPI are the steps that are taken out of the shell script and moved to this workflow. The dist.yaml workflow file utilizes a secret key that I have generated in PyPI and stored it under Settings > Secrets here. This workflow is only triggered when a new tag is created in this repo (i.e., primarily by running the release Shell script).

[machawk1]

Ok, this process should probably be documented. It's starting to sound a little Rube Goldberg-esque.

[ibnesayeed]

I don't think we need to document something that is of no interest of users. For maintainers of a repo the process is being widely adopted by the GH community that it will become obvious how things are done, especially, these YAML files are rather self-descriptive. I feel like documenting it is similar to if every repo using a Dockerfile were to document what Docker is, how it works, and how to install it. If one has used any CI system before, things will be easy to follow and GH has great documentation on how various pieces work.

[machawk1]

It is not for the users, @ibnesayeed, it is for me. Despite what is being adopted, "future us" would like to know. He has an axe.

[ibnesayeed]

Fair enough! Which steps of the process do you think are not very straight-forward and you need to document them somewhere for future reference? I can try to explain.

[machawk1]

A wiki page would be good that we could link from the README. I think I understand the process but will likely not look back on this GH issue (or PR!), so...adapt the above, in your words of expertise, to an external place.

[ibnesayeed]

I have added some inline documentation in some obvious places where I think you might look when you need some clarifications.