Few comments

1. if you are using ruff --fix, do we separately need ruff?

2. have you run ruff over the entire code base? probably not, can you please do that?

3. there's a lot of specific additions and disabling, I think you can reduce those a bit, e.g. instead of manually disabling different pydocstyle rules (D*), you can disable "D" overall. I haven't gone through all but this is something where opinions can be very different regarding what to enable and what to disable etc.

4. ruff has a configuration target-version to specify what python version the resultant needs to comply to. We can use 3.8 there.

Few comments

1. if you are using ruff --fix, do we separately need ruff?

I don't think so as ruff --fix will fix the files inplace, and the next check if for catching any failures that aren't fixed yet.

2. have you run ruff over the entire code base? probably not, can you please do that?

I am running it locally and will get all failures fixed before marking this PR as ready for review.

3. there's a lot of specific additions and disabling, I think you can reduce those a bit, e.g. instead of manually disabling different pydocstyle rules (D*), you can disable "D" overall. I haven't gone through all but this is something where opinions can be very different regarding what to enable and what to disable etc.

I agree with this I am getting it disabled and will also request a review on what to disable once the PR is in a good state.

4. ruff has a configuration target-version to specify what python version the resultant needs to comply to. We can use 3.8 there.

Yeah going to add the target-version

I don't think so as ruff --fix will fix the files inplace, and the next check if for catching any failures that aren't fixed yet.

That's not necessary. ruff fixes the failures it can fix by default, and flags the result anyway, so second one is unnecessary. However, I think it makes sense to format first before linting, so you may want to consider switching.

Now here's a point of discussion: does it make sense to have both ruff and black as formatters? ruff linter has been for a while and it's quite standard now, but the formatter is quite new. Should we replace black with ruff? I am not sure if it's a direct one-to-one corresponence in rules.

I am not sure if it's a direct one-to-one corresponence in rules.

Even if rules correspond, what I realize that we also need to think about downstream developer workflows. E.g., how will the instructions for linting change, see https://www.sktime.net/en/latest/developer_guide/coding_standards.html - and would we be breaking downstream environment setups? Cannot see how, but just putting this for discussion as a point of consideration.

I am not sure if it's a direct one-to-one corresponence in rules.

Even if rules correspond, what I realize that we also need to think about downstream developer workflows. E.g., how will the instructions for linting change, see https://www.sktime.net/en/latest/developer_guide/coding_standards.html - and would we be breaking downstream environment setups? Cannot see how, but just putting this for discussion as a point of consideration.

I propose that if we decide to completely use ruff we could also update the document for coding standards with our ruff configuration.

small note, I just switched to the PR and updated from main to resolve any merge conflicts.

I also noted that max line length is reduced to 79, I think we should leave it at 88 or we will have loads of code to reformat.

ruff supports notebooks as well (reference https://docs.astral.sh/ruff/faq/#does-ruff-support-jupyter-notebooks), so we should consider whether to replace nbqa linting hooks as well.

I am not sure what is the difference between using ruff directly on *.ipynb files and using with nbqa, may be you know @fnhirwa @sktime/core-developers ?

Yeah I read that ruff support .ipynb as well dropping nbqa.

If this is approved then I would start to update the developer Coding standards sections of the documentation for ruff clarification.

I rebased your branch and was about to force push some commits, but it seems you pushed more. I'll wait it out in case CI starts passing.

If this is approved then I would start to update the developer Coding standards sections of the documentation for ruff clarification.

Please start, I'll review if CI passes. Main review is of course the suppressed messages, as I assume there are no/little manual changes.

If you made some manual changes that affect logic or can be considered subjective, can you point out those please?

Any idea why this CI is stuck for so long?

Any idea why this CI is stuck for so long?

This is something common for macOS runners I recall to see this on many PRs

Any idea why this CI is stuck for so long?

This is something common for macOS runners I recall to see this on many PRs

Yes, I think macos runners are weaker in resources:
https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners#standard-github-hosted-runners-for-public-repositories
and there´s also a concurrency limit across the org.

As a consequence, they tend to be "behind" the other operating systems when there are multiple CI jobs in the queue.

With the new test setup, I think the tests run faster than PR are being created, but not on macos, so I have to regularly skip/cancel and test merged batches at once, around releases.

Is this ready? Assuming the macos tests pass.

Is this ready? Assuming the macos tests pass.

from my end it is, I would like to wait for @yarnabrina confirmation

I don't have any major feedbacks. Few choices of configurations and skips I'm slightly unhappy about, but overall looks good to me.

(Subject to successful CI, of course)

ok - failures are all sporadic or timeout related (known and unrelated to this PR).

I see the docs are included here, so good from my side.