1.10.0 release

[ev-br]

No description provided.

[ev-br]

Merging to match the manually published 1.10

[ev-br]

Nope, no cigar: the deployment error blocks merging. Error details: gh-220

why on earth do we construct a bunch of hoops to jump through, instead of python -m build . && twine upload dist/* <copy-paste the API token> which just works

[rgommers]

This diff looks fine, so we should change the auto-deploy to trigger on something else. It looks like it just takes the version number, which isn't ideal. Better to have to push a signed tag or some such thing.

[ev-br]

The auto-deploy is triggered on a tag, actually: $ git push upstream 1.10 kicks auto-deploy from main. I'm actually not sure what the role of the release branch is in this workflow :-).

The pypi release has been made locally from an identical branch, and ATM the main branch is missing the 1.10 commits.
This deploy failure blocks both syncing main manually (git push upstream main) or merging this branch.

[rgommers]

The auto-deploy is triggered on a tag, actually: $ git push upstream 1.10 kicks auto-deploy from main.

That doesn't sound right, it builds the tagged commit, and that commit can be on any branch:

array-api-compat/.github/workflows/publish-package.yml

Lines 3 to 8 in cdd1c8d

	push:
	branches:
	- main
	tags:
	- '[0-9]+.[0-9]+'
	- '[0-9]+.[0-9]+.[0-9]+'

And then the actual upload to PyPI is done only if the build is from a tag rather than from main (so main is only to test if the workflow is working):

array-api-compat/.github/workflows/publish-package.yml

Lines 108 to 109 in cdd1c8d

	- name: Publish distribution 📦 to PyPI
	if: github.event_name == 'push' && startsWith(github.ref, 'refs/tags')

[ev-br]

Indeed, the upload is from the tag, here I stand corrected. The point about main and 1.10 tag being out of sync still stands. I can try pushing a signed tag for 1.10.1 or something. Feels like debugging in prod though :-).

[rgommers]

I think the right fix is to add an extra commit here bumping the version number to 1.10.1.dev0, that is needed anyway. That should avoid the current failure and make this PR mergeable in a regular way. If not, I can merge this bypassing branch protection.

The second part of the fix is to just not do the manual upload again, but follow the release procedure in the docs. Trusted publishing may need a small tweak, but it should work fine unless there are test failures.

[rgommers]

The point about main and 1.10 tag being out of sync still stands.

Please do confirm that the commit in this PR is the actual commit you tagged as 1.10.0.

[rgommers]

Feels like debugging in prod though :-).

Yeah that's a generic problem with trusted publishing - when it works it is great, and when tests are flaky it's not so great. Anyway, please reserve judgement until you've tried it a few times according to the docs.

[ev-br]

OK, I tried bumping the version in this branch, but it is still help up by a failed upload IIUC.

Please do confirm that the commit in this PR is the actual commit you tagged as 1.10.0.

Confirmed:

$ git co release_1.10
Already on 'release_1.10'
$ git diff HEAD..1.10
$ git diff 1.10..HEAD
$

please reserve judgement until you've tried it a few times according to the docs.

No judgement from me. Just an observation that the total time spent on this already is way larger than not using all this trusted publishing. Even if we don't include Aaron's participating in pypa/gh-action-pypi-publish#283
Am ready to believe there are reasons to still prefer it, whether I see them or not.