Create release.yaml for GitHub Actions based PyPI package releases

carlthome commented 1 year ago

What?

Introduce a package release workflow for building and distributing msaf to PyPI.

Install workflow on PyPI

Login to https://pypi.org/manage/account/publishing/ and fill in GitHub.com repo details under "Add a new pending publisher" as per this screenshot:

Usage of workflow on GitHub

Update package version in Python code.
Create a GitHub Releases release as repo owner here: https://github.com/urinieto/msaf/releases
Watch the GitHub Actions workflow run. Once ✅ the newly built package should be on PyPI here https://pypi.org/project/msaf/

Examples

carlthome commented 1 year ago

Also, @urinieto we can pair program this if you wanna! Think one complication is that mir_eval is currently broken on PyPI with recent Python versions, and thus needs to be released too.

urinieto commented 1 year ago

Before merging this, I'd like to understand: why would this be better than this script? If it's superior (which looks like it is), we should remove the script too, as part of this PR.

carlthome commented 1 year ago

Before merging this, I'd like to understand: why would this be better than this script? If it's superior (which looks like it is), we should remove the script too, as part of this PR.

The script looks very nice indeed as it's easy to understand. The benefits of publishing to PyPI through GitHub Actions:

Clearer connection between what's on PyPI and what's on the default branch on the repo.
No need to install anything locally to publish a new release (e.g. if contributors make fixes, you just need to go to https://github.com/urinieto/msaf/releases and click to create a new git tag in order for the package to end up on PyPI)

My hope is that adding a workflow will make it easier to have new commits be pip install msaf:able for library users. E.g. having more patch releases (e.g. a v0.1.71 for having NumPy compatibility again would be nice).

Side note: There's also the potential of combining automated testing with package publishing (i.e. CI/CD), to make sure what's released has been publicly tested for all users to see. This helps to avoid situations where what's been tested isn't actually what's been released (a dirty local repo being a classic oops, for example).

carlthome commented 1 year ago

Should we delete .travis.yml and .travis_dependencies.sh too in this PR?

urinieto commented 1 year ago

Great explanation, thanks! This looks good, I'll merge away. Let's remove the travis files on a different PR.

urinieto commented 1 year ago

I tried creating the new publisher on PyPi, but I get the following error:

urinieto commented 1 year ago

Oh, I think I figured it out. I just managed my msaf project instead. Seems like it worked.

urinieto commented 1 year ago

That was so easy! Just released a new version: 0.1.80! 🎉

Release Action: https://github.com/urinieto/msaf/actions/runs/5369346265 PyPi Package: https://pypi.org/project/msaf/0.1.80/

Amazing, thank you so much!

carlthome commented 1 year ago

Wonderful! PyPI release manually tested to work on my end too:

Python 3.9.6 (default, Mar 10 2023, 20:16:38) 
[Clang 14.0.3 (clang-1403.0.22.14.1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import msaf
>>> import librosa
>>> librosa.ex("brahms")
'/Users/carl/Library/Caches/librosa/Hungarian_Dance_number_5_-_Allegro_in_F_sharp_minor_(string_orchestra).ogg'
>>> msaf.process('/Users/carl/Library/Caches/librosa/Hungarian_Dance_number_5_-_Allegro_in_F_sharp_minor_(string_orchestra).ogg')
(array([ 0.        ,  0.32507937,  7.80190476, 24.28807256, 45.83619048,
       45.84489796]), [0.0, -1.0, -1.0, -1.0, 0.0])

urinieto / msaf