PYPI, release etc

[pwoolvett]

1. publishing to pypi - create an account, then

1.1. creating a valid setup.py (+README, ideally)
1.2. pip install twine
1.3. twine upload (https://twine.readthedocs.io/en/latest/#commands)

NOTE: The owner on PYPI (most likely @rafaelpadilla), has to create an account and api token (keep it secret)
NOTE2: There's an alternative pypi server, called tests.pypi (different server, but same implementation), to try out whatever, so we do not pollute pypi.

This is a good girst step. Following, you should decide a workflow to release new versions:

2.1 Only you, in your computer, via command line
This is like the example (1) above, you have total control over what and when it gets released.

2.2 Through a CI service, eg Github actions, triggered after you (or a repo maintainer) accept(s) and merges(s) a PR into master
A typical workflow for this scenario:
2.2.1. pull request merge into master (using github webpage)
2.2.2. A maintainer manually pulls master locally to his workstation
2.2.3. He/she runs git tag major.minor.patch, then git push --tag
2.2.4. Let a CI service publish to pypi (this has to be coded, but its relatively easy to set up)

You decide what the next version of the project will be (typically following semver, alternatively calver), but you could totally disregard it, either intentionally or without knowing. For example, say you've published `1.2.3`, and an incoming PR introduces a breaking change. A maintainer accepts a PR, and manually releases a new version: `1.2.4`. Unknowingly, a user updates `1.2.3` to `1.2.4` thinking it contains only bug fixes, but ends up with a package which broke his codebase...

2.3 Automatically, using the commit comments (a bit more involved but lets the maintainers focus on the pr and its contents instead of the meta)

To do this, there are tools like commitizen and such, which can be set up to

2.3.1 enforce commit messages rules to comply with [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/)
2.3.2 Automatically decide the next version and create a changelog when a PR is merged into master

And, finally, and equivalent CI workflow to the point (2) above,  to publish to pypi

[SJBertram]

Sorry, meant get to this thread earlier.

Just to note that when you push to PyPi then it will need a license. As it stands, the updated license is slightly better that it was but it's still not strictly MIT licensed because of the extra conditions. Anyone with a legal department is going to think twice before using this code at the moment because the additional clauses mean that it's not just a tick-box "yes, that's MIT, go!" approval (even if they are effectively just an extension of credit by copyright notice).

Maybe what you want is an Apache license and a NOTICE file so that you can require referencing in code from there?