Adopt ruff across SciTools?

[trexfeathers]

ruff

ruff is an alternative linter that can replace flake8 and isort, which @bjlittle has discovered. I'll do my best to summarise the arguments for adopting, but I'm a ruff-novice so please edit this as appropriate.

I consider this a decision for all SciTools repositories, as we want to keep our repo architecture aligned wherever possible.

For

• ruff is very fast, so will make pre-commit a more seamless experience
• ruff is very popular (12k stars!), so keeps us in line with the community
• Can replace two of our linting services with one, and could replace more in future

Against

• Owned by a user - charliermarsh - rather than an organisation - PyCQA
• Still experimental - version v0.0.261
• Has more/different opinions to our existing linters so adoption could get quite noisy and there might be some pain points (see some of the comments on adopt ruff cf-units#353).
  Of course, something is worth some pain if it offers benefits

[bjlittle]

Of course, we could adopt it in one repo as a trial and see how it rolls, otherwise how can we see what's evolving?

[trexfeathers]

Cool, I've edited the options

[rcomer]

Question is: which repo? We already have the config for cf-units, but cf-units doesn’t get many PRs for the actual python code, so it wouldn’t give us that much experience with ruff.

[bjlittle]

Great question ...

Well, if it's good enough for matplotlib (#25147), pandas (#50160), scipy (#17812) and xarray (#7458) et al 😉

TBH I kinda appreciate our hesitancy to adoption, but given this thread and the amount of good discussion that it's generated, I kinda now don't understand our aversion to adoption. I think in practical terms we're either in or out. But that's just me.

Clearly I got royally busted by attempting to bring it in through the back door with cf-units, but now that it's all out in the open, and since you're asking ... for me the obvious answer is iris.

I believe there's genuine instant benefit to be had within iris by using ruff e.g., most recently #4721 (comment)

HTH

[bjlittle]

Also, for any (noisy) future style changes, I'd recommend that we keep using .git-blame-ignore-revs.

We've already started that journey, see:

• Replacing numpy legacy printing with array2string and remaking result… #5235
• Adopt codespell #5186

The use of .git-blame-ignore-revs mitigates somewhat against the argument that noisy prs are bad.

[bjlittle]

@trexfeathers When are you going to call it and close this poll?

[trexfeathers]

We've had 4 responses, which isn't a big proportion of our developers. 📢 @SciTools/iris-devs I'll give you another week

[bouweandela]

I'm not too convinced about the advantages listed above:

• On my laptop, running flake8 on the entire iris repo takes 3 seconds and isort less than a second. Considering that writing something worth committing usually takes at least several minutes, a few seconds seems barely noticeable.
• flake8 and isort are also popular choices
• pre-commit already replaces the command to run several tools by a single command

but maybe there are other advantages that have not been listed above? In the linked pull request I saw that @bjlittle discovered more issues with the code using ruff than using flake8.

[bjlittle]

@bouweandela For me it's not necessarily about the speed of ruff, although that is a lovely bonus, it's more from a maintenance perspective that ruff is offering unification nirvana; one tool that does all.

ruff is growing at an incredible pace, and as Charlie Marsh says:

"Ruff can be used to replace Flake8 (plus dozens of plugins), isort, pydocstyle, yesqa, eradicate, pyupgrade, and autoflake, all while executing tens or hundreds of times faster than any individual tool."

I don't have to jump through several different hoops using several different tools, that are all configured in slightly different ways, and most likely in several different files using several different formats.

Having one tool, configured in one file, using one format that replaces our existing hot-fuss is incredibly attractive to me, particularly because a lot of the infra-structure maintenance across SciTools is done by myself. So it simplifies life, generally.

Also, the PR found more issues (and auto-fixed most of them!) on cf-units simply because it was doing more compliance checking than we've ever done before.

HTH

[bouweandela]

Thanks for explaining @bjlittle! Improved linting quality and lower maintenance sound good.

[rcomer]

I think the importance of the speed depends on individual developers and how they use the linters. Personally I just run them via pre-commit at the command line but I know others plug them into their IDEs. I saw a comment that switching from pyflakes to ruff makes emacs noticeably more responsive.

FWIW Matplotlib has currently gone half-way by providing the ruff configuration for any devs that want to use it (matplotlib/matplotlib#25147). It's not yet plugged into mpl's CI as it didn't yet implement all of the flake8 checks that mpl uses.

[cpelley]

Sounds good. Almost an internal detail with linting taking place using pre-commit anyway. However, I do have a couple of potential concerns:

• Potential for overlap with black? - I don't see anything obvious from the repo. readme to suggest that it will always be compatible with black (i.e. core principle of its design). I only glanced at it mind.
• Perhaps more importantly, ruff is a 'off-piste' public repository. I think the decision to use an alternative linter would ideally be something we could adopt in other repositories too (private repositories). As things stand, I think using ruff as part of the github actions via pre-commit within github actions of a private repository (https://github.com/charliermarsh/ruff-pre-commit) would raise some eyebrows with MO policy. EDIT: happy to provide link to internal policy doc offline.

EDIT: Sounds good otherwise though!

[bjlittle]

@cpelley I don't think there is an issue with interoperability with black, see here and here.

Also, the SciTools organisation is in the public GitHub domain, and is not part of the Met Office private GitHub Enterprise. I don't see how MO policy applies here to such public repositories.

• ruff is a 'off-piste' public repository.

Blimey. You make it sound illicit. How disappointing 😞

So, if Charlie Marsh was to create a public organisation and rehost ruff under that, would that make everything "okay"? If it is, then my eyebrows would do more than rise.

[cpelley]

@cpelley I don't think there is an issue with interoperability with black, see here and here.

Ah perfect! 👍

Also, the SciTools organisation is in the public GitHub domain, and is not part of the Met Office private GitHub Enterprise. I don't see how MO policy applies here to such public repositories.
Blimey. You make it sound illicit. How disappointing 😞

Apologies I perhaps shouldn't have used the loaded term and didn't intend to take any judgment on its legitimacy.
I think you are correct since iris is both open but also under 'Copyright Iris' 👍
However it could be that we necessarily deviate from wider adoption for MO private/MO copyright repos. - which is fine.

[bjlittle]

Just so you know...

Seems to me like some of the biggest popular "on-piste" tools are supported by only a couple of developers at most...

That's the harsh reality of the ecosystem that we live in. The many leaning on the shoulders of the few.

So, I find it hard to disambiguate between your so called "off-piste" and "on-piste" packages. Or am I missing something obvious?

[trexfeathers]

So, I find it hard to disambiguate between your so called "off-piste" and "on-piste" packages.

Self-merges might be on a security watch list.

Of course we are somewhat protected by pre-commit's locked down versions. I certainly check the change-logs when versions are updated (does everyone else?)

[bjlittle]

Yeah, the log changes from dependabot and pre-commit are super useful! 💯

[bjlittle]

Interesting... in the two weeks since this poll started ruff has gone from 12k ⭐ to 14.2k 🌟. Jeez 📈

To put that into context:

• flake8 has 2.8k ⭐
• isort has 5.8k ⭐
• black has 32.2k ⭐
• pyupgrade has 2.6k ⭐
• codespell has 1.2k ⭐

ruff was only born in July 2022. So it's early days yet.

[bjlittle]

This is an interesting read, see https://pythonspeed.com/articles/pylint-flake8-ruff/

[trexfeathers]

Ooooh I don't know what to think!

On the one hand: its popularity seems to be primarily due to the speed, which as we've discussed is less relevant in our case.

On the other hand: popularity is important. Iris is written in Python due to its popularity in science - users can be part of a community. We want to be part of a wider developer community, so it's important to use tools that are familiar to other developers.

[bjlittle]

@trexfeathers Totally agreed. It's a difficult balancing act, right?

There's always a risk with adopting exciting experimental packages that are clearly trending, but if everyone stood on the sidelines to observe how would the community reach a tipping point in adoption?

IMHO the same kinda pattern happened when black started to make ripples in the community a few years ago. It was and still is quite divisive.

So it's all a bit of a conundrum. And to be fair, I'm being quite opinionated here just to stoke up a healthy debate. So please wade in, this is a completely safe space i.e., we've just adopted the Contributor Covenant Code of Conduct 🎉

Also, I really don't mind doing a 180° on ruff, but my current opinion at the moment is that ruff is the new black i.e., it's trending like black, not a replacement for black.

[bjlittle]

BTW this PR just landed on ruff... it's almost like they know we're talking about them 🤣

See astral-sh/ruff#4180

[rcomer]

I opened SciTools/cf-units#364, which I think makes it easier to see the difference ruff makes to cf-units.

[bjlittle]

Note that, @tkknight and I are keen to nibble away at #4721, as the iris docstrings need some major ❤️ to conform to a consistent numpydoc docstring standard.

That said, ruff also supports pydocstyle and auto-fixes most of the implemented rules, which could prove to be super handy.

[rcomer]

Well that seems worth having by itself!

[bjlittle]

Another 2 weeks pass ... and ruff goes from 14.2k to 14.8k ⭐

[trexfeathers]

In all the excitement of 🦥 Sprint: May 2023 I forgot about this 😳

Are we happy with adopting in Iris, then after 6 months making the effort to roll out everywhere else?

[ESadek-MO]

I would support @trexfeathers's suggestion, seems like the route to go!

[bjlittle]

15.3k ⭐

[bjlittle]

17.6k ⭐

[rcomer]

Ruff is now hosted under Astral, so the first point can be crossed off the "against" list.
https://github.com/astral-sh/ruff

[trexfeathers]

Just to be clear I'm not against this. Any perceived 'heel dragging' is just prioritising this against other Iris work.

[cpelley]

Oooh the ruff formatter makes it a drop-in for black now too... (except ruff being much faster)

Incredible the extent of what it supports
docs.astral.sh/ruff/rules

The Ruff formatter is designed to be a drop-in replacement for Black.

https://docs.astral.sh/ruff/faq/#how-does-ruffs-formatter-compare-to-black

19.9k ⭐

[tkknight]

This discussion has been going for several months about a tool that is faster and that simplifies the config. I feel at this point this is a no brainer.

I suggest we get SciTools/cf-units#364 over the line and then follow up for implementing ruff in Iris. If @bjlittle is still up for this I am happy to pair up to get this done - my interest is the numpydoc stuff #4721