feat: Migrate to raysect v0.9

[munechika-koyo]

Summary

I applied some changes to migrate cherab into raysect v0.9 and numpy v2

Key changes

• Rename "targetted" into "targeted" Add a deprecation warning for APIs related to the "targetted" name.
• Bump up deps version of raysect, numpy, and cython
• Fix some bugs related to old deps
• Modify CI by applying the latest deps and dropping some obsolete stuff

Note

This PR might have breaking changes based on module, class renaming, so we probably need to consider bumping up the cherab's version as well.

[Mateasek]

Thanks for pushing this @munechika-koyo. To me it seems good to go, but let's wait for @jacklovell to look at it.

[Mateasek]

@munechika-koyo , I just realised you didn't add the chages into the changelog, could you please add it? Thank you

[munechika-koyo]

@Mateasek, I added some.
I didn't notice, but many of the changes are related to formatting, which seems to have happened automatically by my code formatter settings.
If they are really superfluous, I would revert as many as possible.

[skuba31]

Dear @munechika-koyo, thanks for this contribution. The dependency update is definitely useful and will improve installation experience greatly. I do appreciate your effort put into the required changes.

Generally, I think that the dependency changes should be implemented ASAP. Therefore, I would really encourage you to focus only on code changes related to the main aim and creating additional PRs for the other. Alternatively, you could create a new lightweight PR with only the dependency changes.

Should the version number be increased also for this minimal change? (1.6.0.dev2 ?)

I do have some more specific comments regarding the other proposed changes.

I would suggest to try minimising the formatting changes that do not improve readability, like spaces or import reordering (only those requiring reasonable amount of effort to remove). In my opinion it is ok to keep some, even though they are unrelated to dependency update. I would also keep changes like not smth in -> smth not in as that follows recommended practise.

Regarding proposed change from targetted to targeted, I am strongly opposed to make this change as part of this PR. Firstly, in my opinion, this change will not improve the code significantly enough to justify new major version itself. Secondly, it seems unrelated to the topic of this PR. However, I am open to discuss this change as part of a new major release. I would suggest to create a new PR separating this change or definitely wait for @jacklovell to comment on this issue.

[skuba31]

Another approach would be to also create descendant classes with old names (targetted) and add a deprecation warning to them. This would allow to have both new and old naming and also clearly indicate to users that a change is coming, eventually.

[munechika-koyo]

@skuba31 Thank you for your helpful suggestions!
I will revert some unrelated changes to this PR.

Regarding the lint/format, I will suggest using a unified management tool like ruff and checking code with it on CI.
I would also create another PR about it. (#488)

Regarding breaking changes, like an API name change, I think it is ok to handle them in a minor version update as well if we follow other package rules (raysectv0.8 -> v0.9 as well).
But I second your suggestion to leave the names and set the deprecation warning.
I would also implement it by creating another PR. (#487)

[Mateasek]

I like the idea of keeping both targeted and targetted variants and adding a deprecation warning. Raysect indeed changed the naming, but I think we should offer users some transition period, it is a good call.

[Mateasek]

Although it might be better to have it in a single PR instead of breaking it in two.

[skuba31]

@munechika-koyo thank you for incorporating the suggested changes. I think that this PR is ready to go now.

I leave to your consideration whether you would merge #487 back to this PR as @Mateasek suggested. I am fine with both options. Combination would make sense as the change is motivated by transition to Raysect 0.9 but it could lead to additional discussion prolonging the processing of this PR.

[jacklovell]

Thanks, this looks good. Some minor changes requested and then I think it's good to go.

I agree about limiting the scope of this PR to just dependency updates: other changes should be dealt with in separate PRs (and some should really have TMC discussions first too).

[jacklovell]

I don't think there's a need any longer to install raysect separate from the rest of the dependencies. A long time ago it had to come from Github sometimes and PyPI other times, so made sense to deal with it differently, but it's about time this was cleaned up. Put it in the "Install Python dependencies" step.

Also, should be raysect==0.9.1 since that's what we explicitly depend on in pyproject.toml and setup.py.

[munechika-koyo]

I agree with you.
Moreover, we might be better off utilizing the dependency info that is configured in only one place (such as setup.py in this case).
Should we use the following command?:

python -m pip install -e ".[opencl]"

[jacklovell]

I think we should continue supporting (and therefore testing against) the oldest Numpy available for each Python version. Not all environments (HPC or other experiment analysis clusters for example) may be amenable to upgrading numpy, possibly due to other packages, so Cherab should where possible not require features in very recent Numpy versions. Testing against old versions is to guard against accidentally using new Numpy functions where they're not always required.

oldest-supported-numpy was a convenient way of doing this, but for now the matrix should be updated with the oldest numpy version supported by each Python release. Awkward the first time, but should be quick to modify on each new Python release.

[Mateasek]

Good job @munechika-koyo, thank you for implementing this change, I think it is really needed. I'm happy to merge this if others (@jacklovell, @skuba31 ) have no further comments.

[skuba31]

Good job @munechika-koyo, thank you for implementing this change, I think it is really needed. I'm happy to merge this if others (@jacklovell, @skuba31 ) have no further comments.

I agree, I have no further comments.

[Mateasek]

Since there are no more requests and comments I'm merging this.