PyPI Action Enhancement

[WesRoach]

Workflow:

git commit -m "message"
git tag 1.2.3
git push --tags

The GH Action for pushing to PyPI should trigger when a tagged commit is pushed to main. The following steps should occur and each step should pass before moving to the next step.

1. Tagged Commit is pushed to main
2. Run Normal CI (Pytest/Linting)
3. Build and upload to testpypi
4. pip install fresh environment based on the version pushed to testpypi
5. validate that testpypi version is valid (re-run tests?)
6. Build and upload to Prod PyPI

[rileyschack]

We want pre-commit and pytest to run on every commit--regardless of tag. Do we also want to push to testpypi on every commit? If so, in our setup.cfg we may need to use style = pep440-pre

[WesRoach]

• pytest/linting on every commit
  • Yes, I meant CI should run for tagged commits as well. We don't want to skip CI and go straight to PyPI.
• Pushing to testpypi on every commit
  • The suggestion from PyPI's docs is to push to testpypi on each commit to "make sure your release pipeline stays healthy!" (at the bottom).
  • I think that sounds like a good idea.
  • Thanks for looking up pep440-pre. The main ReadMe section on Styles seemed to indicate that the default would work but I clearly didn't test it extensively. Either way - the testpypi push on each commit should actually work and the 'untagged' version name isn't it.

Perhaps the requirements could be listed differently:

1. Every commit should trigger CI (pytest/lint).
2. Every commit should release to TestPyPI
3. Every commit with a tag should:
   a. Adhere to (1) and (2)
   b. Test TestPyPI's published package
   c. Publish to PyPI

[WesRoach]

Tried pep440-pre: I'm not crazy about it dropping the hash from a dev version.

Going to try this as mentioned in Versioneer's issue tracker. The issue appears to be the Github action/checkout not pulling in tags when it runs the checkout.

[WesRoach]

Ah, I misunderstood PyPI's requirements. I didn't realize the issue wasn't the 'untagged' as much as PyPI having a standard nomenclature which doesn't allow for '+', hashes (referred to as a "local version identifier"), etc.

Back to pep440-pre like mentioned.

• local-version-identifiers
• https://packaging.python.org/specifications/core-metadata/
• https://stackoverflow.com/a/66243061/4501302
• Cannot use PEP 440 local versions pypi/legacy#731

[WesRoach]

The latest upload from the GH action now places the tag in the correct order, after the latest stable (0.0.3), rather than before as seen with 0.post0.dev1 which was produced from the original run with pep440-pre. I'm not sure what happened on the initial run.