❗ Format plugin authors: If you see the following ❗

09:51:09.16 [ERROR] 1 Exception encountered:

  AttributeError: 'builtins.Digest' object has no attribute 'digest'

FATAL: exception not rethrown
Aborted (core dumped)

You've upgraded to a version past https://github.com/pantsbuild/pants/pull/14865 Upgrading is easy,

input

and

output

are now

Snapshot

in

FmtResult

. The PR includes multiple examples of how to fix your formatter plugin.

Thanks Joshua. We might want to fork the 2.12 docs soon, although ideally after we have a chance to do a 2.11 docs audit so we don't have to copy and paste a bunch

Less boilerplate and better caching for formatters, as promised: https://github.com/pantsbuild/pants/pull/14903 Once this is in, you can delete your lint code for formatters 🎉

Is the TLDR for this that new formatters will come pre-loaded as/with linters, and lint-only plugins are unaffected?

What happens for formatters with dedicated lint-centric commands? Continue to use those with

LintResults

?

Like

black

with

--check

? Still goes away. All formatters will be linters implicitly. Reasons: • On the "success-ish" case the process would have the same input, therefore can be re-used for

lint

(Running

./pants fmt lint

is now faster) • The output is now consistent for all formatters across `fmt`/`lint`. It simply prints a list of files that either changed, or would be changed. (Inconsistent output was extremely annoying IMO). ◦ `stdout`/`stderr` is still logged as

debug

• This also allows us to onboard formatters without "lint"-ing capability

Okay, i'm trying to run through the PR and GDoc to understand, but for running

./pants lint ::

- internally, Pants will now run that plugin's formatter, and then compare diffs?

95% coke . It won't "diff" so much as compare the digests.

Sorry, yeah, I use "diff" in the most generic sense of the word

I saw a note about read-only filesystems ...

It'll need to be addressed, but my approach would just be to give a fallback message about the formatter failing to format a file, which implies a file would fail lint anyways. E.g.

black attempted to write to disk but failed. Please run ./pants fmt to fix formatting.

Ah, okay, I read too quickly over the read-only FS part.

With in-memory FS, I imagine the read-only issue dissapears. And maybe this gets a little faster.

faster, for sure, less file-edit churn. I leave my

ccache

stuff in-memory, and yep - definitely blazes past when I'm building embedded filesystems