Has anyone here played around with building a plugin/custom goals for "local workflows"? We have a fairly sizeable collection of test-runners, utility scripts, etc, that wrap pants, but it's kinda awkward and fiddly. Instead one of my colleagues asked if we could have a prefix like

pants the-repo ...

. It seems technically doable, but I'm not 100% if it's wise.

Are there specific use cases in mind? For example, in what situations would you not want to run these goals?

I don't have a clear understanding of the ask either, so this is also looking for examples. The complaint/ask as I understand it, is that our framework is too unwieldy for quick experimentation, and writing tests is too inflexible (and because ML, very slow...). So I think what they ask is that some things that are currently

pants run file-importing-whole-app.py -- lots-of-args-and-configs

could be simplified to a

pants repo --some-action --plugin=xxx --whatever=yyy

with less code in scope etc. Somewhat blurring the line between Pants, tests, and our app.

I guess I would ask then how much of that unwieldiness is attributable to Pants or to the app framework.

Would it be easier to just set cli aliases?

[cli.alias]
--repo-action1= -- lots-of-args-and-configs

then used as:

pants run file-importing-whole-app.py --repo-action1

It might not completely cover situations like still wanting to pass a few of the configs, but might be able to combine a whole bunch of args into one easily.

I first thought of 'Code Quality Tool', but this sounds more like something in the description of an ergonomic adhoc tool. I do some of https://github.com/pantsbuild/pants/discussions/20368 which is kinda awkward

Similar to Luke’s idea, we set various aliases to things like

run path/to/file.py --

I think the alias approach is definitely helpful, and would at least fix some of the "CLI verbosity" issues. The other side of it is that our application architecture is built on a entrypoints + pip features setup to slice the codebase, from pre-Pants. Emulating entrypoints with Pants was a bit too frustrating so instead we're now importing the world, which means lots of work just ends up with "full invalidation", everything in scope all the time, etc. Effectively there's a single file in our codebase that sits as a bottleneck importing half the codebase, and itself being imported by all our apps. And most of work happens in the "half the codebase" downstream side. The frustration is that most of the time, they don't care about the apps side locally, and they only care about a single recipe... so they want to be able to say "what's the configuration for recipe X? is file Y valid for it? run recipe X with file Y." etc. And the aliases makes the "invocation" side of that easier, but it would still have all the import issues.