SIT-2 Release [main]

[bourque]

For reviewers: Please review the release.yml file, as that is a new file being introduced in this PR. Also please review the release notes and let me know if anything should be added/removed/changed. Everything else has already been reviewed in past PRs.

Change Summary

Overview

This PR marks the release of version 0.1.0 (which is the first release of imap_processing), which corresponds to the completion of SIT-2. This PR is being merged back into main per the nominal git & GitHub workflow and release workflow.

These are the release notes that will go into the GitHub release:

This release marks the successful completion of SIT-2. Further information about what was tested in SIT-2 can be found in this [galaxy page](https://lasp.colorado.edu/galaxy/display/IMAP/SDC-SIT-2) and the [SIT-2 GitHub Project Board](https://github.com/orgs/IMAP-Science-Operations-Center/projects/2/views/4).

## Features
* Added project documentation (via Sphinx & ReadTheDocs), including Style Guide, development practices, and API reference
* Added Actions workflow to automatic documentation builds
* Added Actions workflow to automatic deployment to PyPI upon release
* Added pre-commit hooks
* Added Issue and Pull Request templates
* Added all-contributors section in README

New Dependencies

• pydata-sphinx-theme
• sphinx
• myst-parser

New Files

The only new file to actually review is .github/workflows/release.yml, which is a workflow for uploading the release to PyPI.

Testing

The new release.yml workflow was tested by triggering the workflow upon push. The workflow successfully completed (see here: https://github.com/IMAP-Science-Operations-Center/imap_processing/actions/runs/6341963633).

The 0.1.0 version of the package was uploaded to PyPI: https://pypi.org/project/imap-processing/

To test this, one can pip install imap-processing in a new environment and make sure 0.1.0 gets successfully installed.

[greglucas]

It looks like we already have released the code.
https://pypi.org/project/imap-processing/#history

Did you release that off of main, or the 0.1.0 branch? I don't see any tags, so I'm confused what that release corresponds to and how this workflow will go into that. Maybe that was just a temporary release on push? But, then I think we will get a complaint about a release already existing, so maybe you need to yank that one before triggering this actual workflow release?

[greglucas]

Suggested change

	# Get the name of the build sdist file for later use
	echo "SDIST_NAME=$(ls -1 dist)" >> $GITHUB_OUTPUT

[greglucas]

Suggested change

	outputs:
	SDIST_NAME: ${{ steps.sdist.outputs.SDIST_NAME }}

I don't think we use that here. It is only used in those other examples when combining sdists and wheels, but it looks like you are just doing sdist and avoiding needing this.

[greglucas]

Thinking more about this. Do we need the main branch at all? I think main is just the "currently released version"? So, what if we just kept the branches named their version like you have here?

v0.1.x -> 0.1 series that would contain all 0.1 tags.
v0.2.x -> 0.2 series that would contain all 0.2 tags.

We could keep these branches around then and backport whatever we needed to them. This would also eliminate confusion over what version main is and where we are releasing from and remove this need for a massive PR. Thoughts?

[bourque]

It looks like we already have released the code. https://pypi.org/project/imap-processing/#history

Did you release that off of main, or the 0.1.0 branch? I don't see any tags, so I'm confused what that release corresponds to and how this workflow will go into that. Maybe that was just a temporary release on push? But, then I think we will get a complaint about a release already existing, so maybe you need to yank that one before triggering this actual workflow release?

@greglucas Yes, that release was from me testing out the Actions workflow (it worked!). I think you are right -- I will have to remove this release on PyPI before we make the GitHub release.

[greglucas]

I think you could try to use the test pypi: https://packaging.python.org/en/latest/guides/using-testpypi/ but you also might need to add credentials there and authenticate too so might be more work than it is worth...

Yanking might also not work because the artifacts are still there: https://snarky.ca/what-to-do-when-you-botch-a-release-on-pypi/
So maybe best to just leave it there, and I think you'll still get a failure in the release because it will say "hey this version already exists".