Releasing unyt 3.0

[ngoldbaum]

I think we're now in a position where we can ship unyt 3.0.

• Are we ready to do that?

  • We may want to look at the open issues, in particular #346.

• Are downstream users ready?

  • I think yt will work out of the box. Is that true @neutrinoceros?
  • @JBorrow can you weigh in about your usages of unyt for swift?
  • @jzuhone what about PyXSIM?
  • @brittonsmith ytree?
  • @l-johnston?
  • Does anyone know any of the maintainers of other reverse dependencies listed here?

• The docs should probably get a once-over?

Anything else we should do?

[ngoldbaum]

@langmm for yggdrasil too

[neutrinoceros]

yt has been continuously tested with unyt's dev branch and most recent releases explicitly pin unyt to <3. The plan is to remove this pin as soon as unyt 3.0 is released if all goes well, but even if it doesn't we're covered.

[neutrinoceros]

Low priority but I'm thinking this major bump could be the opportunity to get rid of long standing deprecations ?

[ngoldbaum]

Yeah if you’d like to poke at that feel free. Also an opportunity to bump minimum supported versions of downstream dependencies.

[neutrinoceros]

Off the top of my head I don't think we currently have incentive for bumping sympy or numpy, as I don't think we actually have any version-dependent code now, do we ? I'll work on expiring deprecations.

[neutrinoceros]

there's a TODO embedded in the code that should be addressed before the release https://github.com/yt-project/unyt/blob/7c88ad6e5097b0c6fdbb75633a5886b7722bc237/unyt/array.py#L2662-L2665

[neutrinoceros]

I don't think we actually have any version-dependent code now, do we ?

Answering my own question: we do have a couple tests that could be simplified if we dropped numpy<1.19 (which is more than okay to do by now, following https://numpy.org/neps/nep-0029-deprecation_policy.html#support-table)

see https://github.com/yt-project/unyt/blob/7c88ad6e5097b0c6fdbb75633a5886b7722bc237/unyt/tests/test_array_functions.py#L865-872

https://github.com/yt-project/unyt/blob/7c88ad6e5097b0c6fdbb75633a5886b7722bc237/unyt/tests/test_array_functions.py#L1590-1608

let me know if that's okay with you

[ngoldbaum]

Makes sense to me

[JBorrow]

The only thing that broke things for us was the deprecation of input_units being turned into an error (from where we subclass unyt_array). Other than that we seem to be good to go.

[neutrinoceros]

The docs should probably get a once-over?

@ngoldbaum seems to me that's the last thing we need. Are you able to do it ? Do you need a hand ?

[ngoldbaum]

I’ll try to get to that this week and then prepare the release.

[neutrinoceros]

alright, thank you !

[brittonsmith]

I think ytree should be ok.

[jzuhone]

pyXSIM should be fine.

[neutrinoceros]

@ngoldbaum I guess you're busier than you expected. I have time to go over the docs tomorrow if you'd like a hand.

[ngoldbaum]

Hey sorry, I was overly optimistic and am in the middle of several big things in my personal life that are occupying my free time. Is there a need to get this release out ASAP? I'd still like to give everything a once-over before doing the release, but it may take a few weeks. More eyes are better so please go ahead if you'd like as well.

[neutrinoceros]

Is there a need to get this release out ASAP?

no actual rush that I know of, just a personal itch. Ok I'll give it a go !

[ngoldbaum]

Would anyone mind if we dropped support for Python 3.8? Does yt still support Python 3.8?

[neutrinoceros]

Yes yt still supports 3.8 and in fact it's expected to be a tough one to drop there (https://github.com/yt-project/yt/issues/4302). I would prefer we keep it compatible with unyt 3.0, but after that I have no objection.

[neutrinoceros]

@ngoldbaum In the last few months, we've seen tests breaking against numpy 2.0.0dev a couple times (most recently #442).

Quoting https://github.com/numpy/numpy/issues/24300

2. If you rely on a large API surface from NumPy's Python API, also consider adding the same numpy<2.0 requirement to your metadata. Rationale: we will do a significant cleanup (see NEP 52), so unless you only use modern/recommended functions and object, your code is likely to require at least some adjustments.

This seems to apply very well to unyt, would you agree ?

Also, I'm now in favour of dropping support for Python 3.8 (or at least, not opposed to it), as it seems less and less reasonable to keep applying yt's concern to unyt.

Lastly, and I don't want to put any pressure on anyone, but I'd just like to re-establish that I am available to prepare and publish the 3.0 release if need be, but I'd totally understand if you prefer just doing it yourself ! Just let me know :-)

[ngoldbaum]

I was about to do the 3.0 release a few months ago, but Clement's nitpicking code review on the pull request I issued to fix up the code coverage on code Clement added was enough to turn me off from working on unyt much since then.

If you need a unyt release for your own purposes, go ahead and do a release as you all see fit.

I am going to disable notifications on this repository now because getting notifications about it invariably raises my blood pressure.

If you need me, please email me directly. I would prefer if Clement doesn't contact me though.

[neutrinoceros]

I am sorry you feel that way, and as much as I hoped that we could continue working together, I will respect your wish.