Replace flake8 and isort with ruff

[gadomski]

Related Issue(s):

• Closes Add ruff #1030

Description:

ruff is fast and has good momentum. See https://beta.ruff.rs/docs/faq/#which-tools-does-ruff-replace for the list of tools that ruff can replace.

PR Checklist:

• Code is formatted (run pre-commit run --all-files)
• Tests pass (run scripts/test)
• Documentation has been updated to reflect changes, if applicable
• This PR maintains or improves overall codebase code coverage.
• Changes are added to the CHANGELOG. See the docs for information about adding to the changelog.

[pjhartzell]

Looking across the STAC ecosystem (pystac, pystac-client, stac-fastapi, stactools, the stactools packages template), the consistency of configuring formatting and linting is a little loose. So I'm hesitant to throw another configuration (and tool, in this case) into the mix.

I do see an improvement of a few seconds with pre-commit run --all-files on my local machine. But is the benefit worth the added entropy? Are we looking at standardizing to use Ruff across the core STAC libraries? If so, it would be great to also standardize the available "scripts to rule them all" offerings and any remaining format/lint config files after moving to Ruff.

[gadomski]

Agreed on the general point that there's a lack of standardization in the ecosystem. We've had a defacto rule of "do what PySTAC does" w.r.t. tooling and style (though sometimes we do it backwards, e.g. w/ the pytest upgrade). In this case, ruff is replacing two tools (flake8 and isort), so you could argue we're simplifying :-).

Are we looking at standardizing to use Ruff across the core STAC libraries? If so, it would be great to also standardize the available "scripts to rule them all" offerings and any remaining format/lint config files after moving to Ruff.

I think this is a good idea, and maybe this change is a good opportunity to do a larger standardization push. I personally find it slightly irritating that pystac and pystac-client build their docs differently, e.g. Just because we're in the middle of the backend breakout, I'm hesitant to change stac-fastapi just yet, but if we publish what we're doing it won't be hard to apply it to stac-fastapi after the breakout as well.

I'll cook up a document describing this policy, and then we can roll PRs into the repos?

[pjhartzell]

Sounds good.

[gadomski]

I'll cook up a document describing this policy, and then we can roll PRs into the repos?

I've created a draft "developer guide", currently hosted here: https://github.com/gadomski/stac-utils-developer-guide. Once it's a bit more polished, I'll propose a transfer to the stac-utils organization, and once that goes it'll be available at (404 for now 👉🏽 ) https://stac-utils.github.com/developer-guide.

My current guide includes our recommended tooling stack, based on this repo: https://www.gadom.ski/stac-utils-developer-guide/languages/python.html#tooling.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.34%. Comparing base (2d2eb90) to head (2ef59a3).
Report is 269 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1034   +/-   ##
=======================================
  Coverage   90.34%   90.34%           
=======================================
  Files          47       47           
  Lines        6213     6213           
  Branches      929      929           
=======================================
  Hits         5613     5613           
  Misses        422      422           
  Partials      178      178           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.