Compatibility fixes for unyt3.1.0

[kyleaoman]

A new version of unyt is about to be released. This has some new features and bugfixes that we should take advantage of.

This includes changes previously proposed in #221, but I'm combining them as it's all to do with changes in the same version of unyt.

Todo:

• Dependencies need to be pinned. I've been loosely testing that everything works with numpy versions 2.3.4 and 2.4.1, but this should be done a bit more carefully before merging. I don't have the brainspace to overhaul the CI to test various version combinations right now but checking carefully by hand on this one would be a good idea. Also worth checking a few astropy versions particularly in conjunction with numpy 2.4.1. We should pin unyt to >=3.1.0 on this one, for sure. I think we should not pin to numpy>=2.4.1 because it's very new and in particular numba will be lagging behind this.
• Wait for unyt to actually release 3.1.0.
• Make sure RTD builds docs successfully, config was tweaked with new deps management setup. Can either switch on PR builds on RTD, or just see if it breaks on merge I guess.

Closes #285
Closes #253
Closes #286

[kyleaoman]

Test failures seem to be because my attempt to test against unyt's main, currently erroneously set to version 3.0.1dev0 (typo for 3.1.0dev0, I presume), gets overridden by installing 3.0.4 from pypi. I think this is because we have requirements both in requirements.txt and pyproject.toml (well and also because of the typo in unyt). This means 3.0.4 installs as a dependency when swiftsimio installs, AFTER we already installed main when installing requirements :(

[kyleaoman]

@JBorrow unyt released today, so when you get a chance... If you have views on versions for dependencies that's also helpful.

[JBorrow]

Code looks good to me insofar as I understand the unyt internals.

[JBorrow]

Can we not allow unyt to handle our numpy version pinning for us?

[kyleaoman]

Can we not allow unyt to handle our numpy version pinning for us?

No, we require more recent numpy. This is because I wrote most of the support for numpy functions after 2.x existed and couldn't summon the courage to do all the branching that you need to support 1.x and 2.x simultaneously. unyt does do that so they still support older versions. We could use their code as a template for what would need to be added to be more backwards compatible, but we've required 2.x for a while and no one has complained that they can't use 1.x so there's probably no point.

[kyleaoman]

@JBorrow if you're happy with the changes can you merge and mint a release (could wait for John's PR for release, it seems close to ready too). Main thing to keep an eye on that's not otherwise checked is the RTD build. I don't think I broke it but have no way of checking - can't see the logs or anything. Also consider switching the default docs view from "latest" to "stable", that will be the version that most users want. There's a setting in the RTD console for that. I'll push a commit in a sec to update the link on the README to not point specifically to "latest" but just the RTD site and let it decide what the default version is. I already updated the github sidebar link.

FYI the change that I made was to build the docs from the github repo - it was always building from the pypi version, so afaict both "latest" and "stable" were actually the most recent pypi release. RTD is smart enough to build "latest" from HEAD of master and "stable" from the most recent version-number-like tagged commit, we should be letting it do that and that's what I've got it set to do now in the .readthedocs.yaml. Defaulting to "stable" then makes sense since most users will have the pypi version and having unreleased changes from master can be confusing. It does mean that any updates to the docs effectively require release, though.