Support PyPI Trusted Publisher for making releases

[MridulS]

Fixes https://github.com/econ-ark/HARK/issues/708

Keeping it in draft mode for now as we still need to turn on trusted publisher on pypi side https://docs.pypi.org/trusted-publishers/adding-a-publisher. I can do that if folks think we should go ahead with this :)

[mnwhite]

So the idea is that rather than doing the old process of manually pushing to PyPI and concurrently making a release commit / tagging a version on GitHub, we would just do a version tag here and that would automatically propagate to a PyPI release?

[MridulS]

we would just do a version tag here and that would automatically propagate to a PyPI release?

Indeed! This is the recommended security practice too now.

[mnwhite]

@llorracc @akshayshanker @alanlujan91 See above. I vote for this.

[llorracc]

@MridulS, thanks for the input. This sounds like a good idea.

[mnwhite]

Alan pointed out that this change is part of the (oddly named) PR #1514. The current plan is that after we release v0.16.0, we will then quickly do v0.16.1 with only packaging / technology changes. So let's put this on hold for (hopefully) a short while.

[alanlujan91]

"cookie" https://github.com/scientific-python/cookie

[mnwhite]

I'm sure it means something, but my point is that the one word title with no verb isn't clear. My understanding/definition of "cookie" is:

1. the round sweetdiscs that we om-nom-nom
2. a file that websites deposit in your webcache

The cookie PR is related to neither, and the word "cookie" doesn't appear in the description anywhere.

[MridulS]

@alanlujan91 I was just overwhelmed by looking at all the merge conflicts it will create so trying to move in baby steps :D

[mnwhite]

@MridulS Can this be merged? Simplifying the release workflow would be great.

[MridulS]

I set it up on pypi side too, we can test it out with the next release. Ideally shouldn't really break anything :)

If anything does go wrong, the release can be uploaded manually!