Tangentially related, I'm wondering if a

cookiecutter

script for common tasks would really speed up stamping out new linter/formatters: https://github.com/cookiecutter/cookiecutter (The result doesn't have to be perfect, but any templating goes a long way)

I personally really don't like templates like that unless you make the conscious choice that you don't have time to clean up the thing needing templating. We may have made that choice already, but I'm not sure. Hopefully we can de-oilerplate boilerplaty common tasks instead.

You lost me 😑 template-script or no-template-script I'll be applying a template to my use case. The difference is "I copied this code from the documentation and adjusted" vs. "I ran this script to stamp out what I needed and adjusted"

If the code to "copy" is minimal, then there is no need for a template is the idea. I personally would always rather read, fully grok, then do it by hand. I may be fairly extreme in that regard.

I don't disagree with you, in principle, but you have to start where you are. Where you are is: • The current Pants engine makes "minimal" boilerplate difficult • There's 3 places I'm needing to look and apply various aspects of in order to do something hopefully simple. (The docs, the example repo, and Pants itself) Additionally, there'll always be some upgrade cost. I'd personally rather re-run the cookiecutter which ideally has the latest changes, and compare the old to new than to have read migration/upgrade guides.

I'm not sure your 1st bullet is necessarily true. I do agree with where we are. If it was unclear, my:

We may have made that choice already, but I'm not sure. Hopefully we can de-oilerplate boilerplaty common tasks instead.

Truly meant I'm not sure. @hundreds-father-404 is likely the definitive voice here. He'll be the one who does or does not have plans to clean up adding a linter.

Perhaps if my previous post about flailing about in the documentation didn't exist (I.e. the docs provided a thorough guide for my specific use-case) then I'd just skip the English paragraphs, copy the lightly-templated-for-the-docs example snippets and modify as necessary. Then the cookiecutter wouldn't add much more than that.

Yeah, this is where I think @hundreds-father-404 will need to chime in. I just don't like developing that way.

(And because I didn't say it, but worth saying for the sake of context) The linter/formatter I'm wanting to add is Buildifier. I'm only adding it because we're adding Pants to the monorepo just for format/linting/checking and then will incrementally adopt it for build+test. While we're still using Bazel, we'll still need to run

buildifier

. Running it in Pants is ideal because (gestures broadly at all of Pants' great features) When we're off Bazel completely, I get to remove

buildifier

support 😈

Tell me about it. I think i was 1 / ~1k before I got help at Twitter.

How you didn't shit literal diamonds is beyond me

It definitely had an effect. My dirver's license photo is from that time and it does not look like me to mine own eyes.

Annnndn success:

joshuacannon@CEPHANDRIUS:~/work/techlabs$ ./pants lint path/to/BUILD

✓ buildifier succeeded.

To add some context from someone who literally started their first plugin last night - I see both points. I spent a fair amount of time reading through the docs, the example-plugin repo, and then pants source to just figure out where to start. Once I was "started" (had something that could compile/run and do-nothing), everything kinda made more sense and I have a clear path forward where I should put code, how it all relates, and what to do next. For me, a cookie cutter script, or template repo, or whatever, would actually just be a common skeleton with comments on where to find more information - but very little actual code. More just structuring files and compilable - rather than filling out the content of those files. Maybe some empty methods at most.

I agree with trying to first reduce boilerplate before automating copying and pasting the boilerplate. That's much more in-line with Pants's philosophy For example, I've been wanting to experiment with how to get rid of that whole

python_formatters.py

file where you have to set up each distinct language with 50 lines of boilerplate. https://github.com/pantsbuild/pants/pull/14122 taught me some new design patterns with rules that might make that possible John's assessment is right - I intentionally did not generalize in the beginning because it was too soon, "premature generalization". We now have 8+ formatters/linters, we're ready to start simplifying things. And the Rules API means a plugin that diverges from the standard way can do its own thing just fine.