I just finished upgrading my plugins to support 2.15 (from 2.14). 😰 the Fmt/lint plugin API changes were a bear this time because I had to not only change the rules and add some new rules, I also had to add new subsystems in each of my plugins where I didn't need a subsystem before. Good changes, just more churn with less tooling to help me do the upgrade than in previous releases.

Technically you should've had a subsystem. It's a bit of a harsh viewpoint, but part of my motivation for these declarative changes is pushing conformity. You could (and maybe should) argue plugin authors maybe shouldn't need the same conformity that core pants plugins do. But I also think to the end users it's all "pants". They don't see the difference.

Technically you should've had a subsystem.

Ah, but I used

PexFromTargetsRequest

to run the "linter" and "formatter" defined within the repo. So, there was no subsystem before as I did not need to define any external tool details.

The subsystem requirement is more of a forcing function for your

--skip

option

As far as upstreaming goes, If we could have an abstract

PexFromTargets

that can act as a formatter and a linter, then I could delete 3 of my plugins which are just light wrappers to integrate in-repo scripts into pants

fmt

and

lint

goals.

There's an issue that would get us there

The adhoc_tool stuff?

No, it'd be shifting the tools from their own lockfile into being specified as a target if your own resolve.

Fascinating. I don't think I've seen that issue/discussion. Got a link?

pants-plugins lines changed in the upgrade: [+354 -187] https://github.com/StackStorm/st2/compare/pants-upgrade-2.15 In general, I don't care about LOC... But, it makes a huge difference in getting people to review changes. The smaller the LOC, the faster I'll get a review.

Hmm unless you have custom partitioners you should theoretically be having fewer LOC.

https://github.com/pantsbuild/pants/issues/12449

This has to do with moving the version definition for existing backends from pants.toml into BUILD files. I don't think it would help with eliminating my fmt/lint plugins by taking a random target and saying that its output should be used as a fmt or a lint tool.

If that target is a

python_requirement

that's exactly what that ticket describes

It's not, it's an in-repo python_sources / entry point

...honestly that might even work too

True.

FWIW we now have adhoc tests through shell commands. I filed a ticket to do the same for fmt and lint

My "custom partitioner" just passes field_sets to my fmt rules instead of the files list. Very short.

@rule()
async def generate_schemas_partitioner(
    request: GenerateSchemasViaFmtTargetsRequest.PartitionRequest,
) -> Partitions[GenerateSchemasFieldSet, _EmptyMetadata]:
    return Partitions.single_partition(request.field_sets)

Technically a formatter/linter should be anything `run`nable in a sandbox

Not quite. I was only able to use

partitioner_type = PartitionerType.DEFAULT_SINGLE_PARTITION

for 1 lint rule and 1 fmt rule. The other 2 fmt rules needed field_sets instead of files.

You need field sets, do you subclass the Target formatter subclass?

yeah

Ah ok

lol

Would love to make your case simpler, but not in the hot path, so to speak

Blast. That assumption that fix/fmt deals with files (and therefore batch elements is a list of strings) bit me. Something in rust is trying to cast my FieldSet to PyString, and it gets stuck in an endless loop. My plugin tests pass, but my test rule requests must be bypassing the logic in the fmt goal that triggers that. 😞 So: https://github.com/StackStorm/st2/actions/runs/4141002684/jobs/7160185247 `[ERROR] panic at 'called

Result::unwrap()

on an

Err

value: "Field

globs

was not convertible to type alloc:vecVec&lt;allocstringString&gt; PyErr { type: <class 'TypeError'>, value: TypeError(\"'APISpecFieldSet' object cannot be converted to 'PyString'\"), traceback: None }"', src/nodes.rs:770` Oddly enough, I don't get the rust ERROR locally, I only get the `Filesystem changed during run: retrying

Lint

in 500ms...` message in an endless loop. I guess I'm not done updating my plugins for 2.15

The core code is opaque to partition element types. Put another way, whatever your partition rule returns gets passed into your runner rule. I'm that way, it doesn't have to operate in field sets or files