Adds first PyPI publishing workflow

[binaryaaron]

Adding in the proper GH action file to handle both

• pypi releases (test and prod)
• GH releases (draft and real)

The test path should get triggered on PRs to main; the others will only get triggered if we add a tag.

[sfriedowitz]

Why are these jobs running as part of the PR checks? It seems like the triggers might be incorrect if this is supposed to only run on publishes to main or GH releases?

[binaryaaron]

Why are these jobs running as part of the PR checks? It seems like the triggers might be incorrect if this is supposed to only run on publishes to main or GH releases?

Only the draft ones are done when there is a tag. so this should not run if you make a tag-less PR against main.

can basically have a branch like "dev-0.2.0" and when it's ready to release, make a PR against main with a tag v0.2.0, which will then trigger this. after actual changes are landed, the non-draft version should run from main, and push the wheels to real pypi.

[veekaybee]

Could you add some instructions in contributing around this and how to add a tag, i.e. is this a git tag? @binaryaaron

can basically have a branch like "dev-0.2.0" and when it's ready to release, make a PR against main with a tag v0.2.0, which will then trigger this. after actual changes are landed, the non-draft version should run from main, and push the wheels to real pypi.

[sfriedowitz]

Suggested change

	# Build and publish to PyPI
	name: Build and publish to PyPI

Should name the workflow a as a whole, or else it displays weird in the PR checks

[sfriedowitz]

I'm a bit confused by the release process here, my thought was that we would create a GH Release with a newly created tag based off the main branch, and that would trigger the publishing actions to real pypi.

I'm fine to go with this to give this system a shot, though. We can always tweak down the line if the triggers are not exactly as we'd expect.

Edit: This is the release trigger I was thinking of (https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#release)

[binaryaaron]

I'm a bit confused by the release process here, my thought was that we would create a GH Release with a newly created tag based off the main branch, and that would trigger the publishing actions to real pypi.

I'm fine to go with this to give this system a shot, though. We can always tweak down the line if the triggers are not exactly as we'd expect.

Edit: This is the release trigger I was thinking of (https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#release)

that'd be fine too! this is more automation than that; if it doesn't work happy to simplify it / create a better overall structure for using GHA.

I'll add docs, @veekaybee , ty for the reminder.

[veekaybee]

🚀🐍

[sfriedowitz]

committable suggestions for consistency in formatting of contributing guide

[sfriedowitz]

Suggested change

	`.github/workflows/publish.yaml' contains the GitHub Action used to do releases and push wheels to PyPI.
	`.github/workflows/publish.yaml` contains the GitHub Action used to do releases and push wheels to PyPI.

Ticks were off, so was not displaying code style

[sfriedowitz]

Suggested change

	There are two subcases - draft/dev and the 'real' release.
	There are two cases - 'draft' and the 'real' releases.

[sfriedowitz]

Suggested change

	If a contributed opens a PR to `main` with a git version tag (e.g., `vX.Y.Z`) , the draft process will start which does the following:
	If a contributer opens a PR to `main` with a git version tag (e.g., `vX.Y.Z`) , the draft process will start which does the following:

[sfriedowitz]

Suggested change

	this is to ensure the full process works before merging to main.
	This is to ensure the full process works before merging to `main`.

[sfriedowitz]

Suggested change

	### Draft / Test releases
	### Draft releases

[sfriedowitz]

Suggested change

	### Real release
	### Real releases

[sfriedowitz]

Suggested change

[binaryaaron]

I'll add some followups after this one; i think using labels might be a little easier both from a user perspective and event filtering perspective.