1.4 release

[asmeurer]

No description provided.

[matthewfeickert]

@asmeurer n.b. #51 (comment) as a heads up to potentially avoid any rough spots with the release.

[asmeurer]

OK. I didn't actually make the release yet because of some CI issues, so if there's fixes that should be made we can push them here.

[matthewfeickert]

OK. I didn't actually make the release yet because of some CI issues, so if there's fixes that should be made we can push them here.

Ah sorry I just saw this after already opening PR #57. If you want you can migrate that commit over here.

---

My warning in #51 (comment) about problems with tags and release environments only pertains to TestPyPI publishing (which happens on tag)

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

Lines 90 to 99 in 31aec62

	- name: Publish distribution 📦 to Test PyPI
	# Publish to TestPyPI on tag events of if manually triggered
	# Compare to 'true' string as booleans get turned into strings in the console
	if: >-
	(github.event_name == 'push' && startsWith(github.ref, 'refs/tags/v'))
	|| (github.event_name == 'workflow_dispatch' && github.event.inputs.publish == 'true')
	uses: pypa/[email protected]
	with:
	repository-url: https://test.pypi.org/legacy/
	print-hash: true

as PyPI publishing happens on creation of a GitHub Release

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

Lines 101 to 105 in 31aec62

	- name: Publish distribution 📦 to PyPI
	if: github.event_name == 'release' && github.event.action == 'published'
	uses: pypa/[email protected]
	with:
	print-hash: true

Though unfortunatley https://github.com/orgs/community/discussions/62991 still requires you to change deployment branches to all (basically removing that extra protection) to get the tag workflow to run.

[matthewfeickert]

Sorry also needs PR #58.

[asmeurer]

The test pypi publishing failed https://github.com/data-apis/array-api-compat/actions/runs/6176938155/job/16768843618

[matthewfeickert]

The test pypi publishing failed https://github.com/data-apis/array-api-compat/actions/runs/6176938155/job/16768843618

@asmeurer Sorry to hear that.

Token request failed: the server refused the request for the following reasons:

* `invalid-publisher`: valid token, but no corresponding publisher (All lookup strategies exhausted)

This makes it seem like there is no publisher setup on TestPyPI like we discussed on #51 (comment). Can you show me a screenshot of https://test.pypi.org/manage/project/array-api-compat/settings/publishing/ ?

(edit): I meant #51 (comment)

[asmeurer]

So I need to set up everything separately on test PyPI for this to work? I'm not sure if I want to do that, especially since test PyPI apparently gets cleared every once in a while.

[matthewfeickert]

So I need to set up everything separately on test PyPI for this to work?

(Yes, if you want to use TestPyPI, but) TestPyPI is totally optional. You can delete the

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

Lines 90 to 99 in ae2d029

	- name: Publish distribution 📦 to Test PyPI
	# Publish to TestPyPI on tag events of if manually triggered
	# Compare to 'true' string as booleans get turned into strings in the console
	if: >-
	(github.event_name == 'push' && startsWith(github.ref, 'refs/tags'))
	|| (github.event_name == 'workflow_dispatch' && github.event.inputs.publish == 'true')
	uses: pypa/[email protected]
	with:
	repository-url: https://test.pypi.org/legacy/
	print-hash: true

block and it won't affect anything else in the publishing workflow (beyond the workflow dispatch publishing to TestPyPI.)

To be clear you can also publish v1.4 to PyPI with the currently merged workflow without issues (even though TestPyPI failed) as

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

Lines 101 to 105 in ae2d029

	- name: Publish distribution 📦 to PyPI
	if: github.event_name == 'release' && github.event.action == 'published'
	uses: pypa/[email protected]
	with:
	print-hash: true

operates under different workflow conditions (it triggers only on GitHub release creation).

I'm not sure if I want to do that, especially since test PyPI apparently gets cleared every once in a while.

Hm, I don't think that I've ever had any releases get removed form TestPyPI in the last 5 years. That being said, I also don't view that as an issue. TestPyPI isn't something that should be viewed as an alternative package index for installing from indefinitley, but more of a check that upload procedures are working and that rendering of the PyPI page works.

[asmeurer]

Oh I see now. I think it makes more sense to me to just have tags, and for the workflow to automatically create the release from the tag.

That being said, I also don't view that as an issue. TestPyPI isn't something that should be viewed as an alternative package index for installing from indefinitley, but more of a check that upload procedures are working and that rendering of the PyPI page works.

My concern is more that if/when they clear it, I'll have to redo everything or else releases will stop working.

[asmeurer]

Anyway, I realized that I did the release wrong (I forgot we don't get the version from the tag automatically in this package), so I removed the 1.4 tag.

[matthewfeickert]

My concern is more that if/when they clear it, I'll have to redo everything or else releases will stop working.

@di (or maybe @henryiii?) might be able to comment more here, but AFAIK there is not a concern of TestPyPI ever removing an entire project. I think the worst that would ever happen is that an old release on TestPyPI might get removed.

I think it makes more sense to me to just have tags, and for the workflow to automatically create the release from the tag.

This is I think more of a personal choice. I generally like to seperate the two steps to provide a clear opportunity to check things are working as expected before deploying to PyPI (as PyPI deployment is "forever"). But that's just my workflow prefernces.

[asmeurer]

@di (or maybe @henryiii?) might be able to comment more here, but AFAIK there is not a concern of TestPyPI ever removing an entire project. I think the worst that would ever happen is that an old release on TestPyPI might get removed.

My concern is based on what it says at https://packaging.python.org/en/latest/guides/using-testpypi/:

Note The database for TestPyPI may be periodically pruned, so it is not unusual for user accounts to be deleted.

I did just setup test pypi (I think). If it ever does get deleted I'm probably not going to do it again, though, because it's seriously annoying.

This is I think more of a personal choice. I generally like to seperate the two steps to provide a clear opportunity to check things are working as expected before deploying to PyPI (as PyPI deployment is "forever"). But that's just my workflow prefernces.

Well as long as we're doing test pypi I don't see an issue, because the workflow should stop if that step fails (presumably).

[di]

We make no promises about TestPyPI and long-term would eventually like to wind it down. While @matthewfeickert is correct that we don't actually "clear" or "prune" it really, I wouldn't advise having any kind of expectation that it or the things on it will continue to exist, and it should really be thought more of as a sandbox for testing and experimentation that won't affect things on PyPI.

[asmeurer]

Tried again, hopefully it all works this time.

[asmeurer]

OK, finally got the release to work. Thanks for your help here @matthewfeickert