Proposed updates to CI testing and release creation

[djhoese]

After talking with @pearu in #136, he said that updating testing and releasing of pylibtiff would be appreciated. Here's what I propose towards that end with some of the gotchas someone unfamiliar with these steps should maybe be aware of. Note none of this is new to me and I have multiple projects doing at least a couple of these things.

1. Package versioning: Use setuptools-scm (https://pypi.org/project/setuptools-scm/) for automatic package versioning based on git tags. You may have also heard of versioneer which is another package that provides similar functionality (but I prefer setuptools-scm). This essentially removes any manual version editing in setup.py. The one downside is you may get some users who don't install the package before trying to use it from source. This will error as the version number for the package isn't generated until you pip install -e . (to make an editable/developer install) or do pip install . to do an in-environment full install. Otherwise, once properly configured, this simplifies so much.
2. Remove Python 2.7 support.
3. Remove travis and appveyor CI
4. Add github action CI
5. Add building of wheels for major platforms to github action CI (I assume this doesn't require libtiff to be installed)
6. Add deployment of sdist and wheels to github actions when a GitHub release is made. This will require @pearu (who is the only PyPI pylibtiff maintainer) to make an access token on PyPI and save it as a secret in this github repository (see "Settings" on this repository).
7. Update release instructions to reflect the new procedure (git tag, push, make github release, done).

Optional long term changes:

8. Remove numpy Configuration usage. I have no idea how this stuff works and it really feels like it obfuscates the whole building process. Especially since there are two of them.
9. Use a changelog generator to make a CHANGELOG.md for every release which will automatically pull from github closed issues and pull requests and format things nicely for user/reader ingest.
10. Drop the extra setup.py command line flags/options/commands. Are they used on a regular basis besides the releasing process?
11. Eventually try moving to only a pyproject.toml and remove the setup.py.
12. A pre-commit with black auto-formatter and lint checking.

[djhoese]

Thinking about it more, maybe as a first round of updates we don't distribute wheels. Too many potential failures and you've never released them before.

[djhoese]

1-8 are now complete except 5 (wheel building). I didn't want to get caught up building wheels and potentially have setuptools pull in the docker image's version of libtiff into the package. The previous release didn't have any wheels and that was OK enough with people. If someone wants to add wheel building to the github actions feel free.

I've also done 10 (drop extra setup.py commands).

Number 11 apparently can't be done because extensions can't currently be defined in pyproject.toml.

I was going to do 9 (changelog), but the one we use in Satpy that I'm familiar with requires annotated tags to determine PRs/issues that have occurred since then. The last release was a "soft" tag so this wasn't possible. The newest release (0.5.0) was an annotated tag so this could be looked into now.

Finally, for 12, I added basic flake8 checks to CI but no pre-commit at the moment.

[djhoese]

@pearu what is your opinion on black and/or other auto-formatters? Have you used pre-commit before? If not, then we can probably close this issue as I've done most of the other stuff.

[pearu]

I know about black but have not used it in the pre-commit context actively (although, it is tempting..). For the pylibtiff project where the commit activity to the code is relatively low, black might be overkill. Accepting PRs that satisfy flake (or some other similar tool) should be sufficient, imho.

[djhoese]

For the pylibtiff project where the commit activity to the code is relatively low, black might be overkill.

Yeah, I've gotten to the point that I like it for most projects I work on especially the low activity ones. It gives me a (false?) sense of comfort that at least the code isn't that hard to read. I don't feel too strongly about adding it here as I also hope to not make too many commits to this project once a few things are fixed.

That said, I just realized this package might be a good candidate as an option for my local python meetup group's hackathon as a refactor task for one group of developers.