#19357 Community plugins versus official plugins & plugin stabilization New discussion created by tgolsson Hey! This started out as a discussion on Slack, and @sureshjoshi rightfully suggested this belongs more here. I'd like to start a discussion around where Pants plugins/backends should live and be developed. To contextualize this, I'm developing quite a few plugins that I use to manage my cluster (k8s + kustomize), build docs (mdbook), manage secrets (bitwarden + secrets-plumbing), and building container images (oci). All of these are on PyPi. I also want to contribute a bit to making Rust a viable language for Pants. And since @lassemand's Rust fmt PR, I have a bit of a workflow dilemma. My issue is that I'm a dogfooding person. I write code, and then I use it until I find an issue. Then I use the fixed version until I need another feature. I add that, and continue. I don't think the way the Pants repo workflows and its release process is very well-suited for that kind of work, and definitely not for quick iteration. It takes a long time for PRs to go through reviews, and even longer to be released. I've gone through four versions of my OCI builder in the same timeframe that Pants has released a single version. If that was upstream and I added a feature now, I fear it'd not be available for downstream users until well after summer. Thus, when I think about contributing to Rust-support and dogfooding that work, every feature needing to be part of a future release makes it very hard to test and adopt in production incrementally. New users cannot be gained on a timescale shorter than a release cycle. New contributors won't see results until months later. Bugfixes can be backported, but there still needs to be a full Pants release. On contrast, a standalone plugin could potentially automate releases of their single tool to run on every commit, and new contributors will have benefit from their work very quickly. I've used Bazel professionally for quite a while and I think the

rules_x

workflow as a plugin flow is much more sustainable as a contribution model. Bazel core is quite lean, and most things are developed independently. This does lead to breakages and incompatibilities, but for the most part it's easy to add new rulesets, and new features in a plugin can be shipped at any point during the lifetime of a bazel version. This means that new contributors (or plugin developers) can form niche communities, with their own interests and their own timelines. There's no need to become a "Bazel contributor" to work on plugins. In contrast, for Pants, it seems like the assumption is that all backends trend towards going upstream. I think that this makes the barrier-to-entry much higher than it needs to be, as potential contributors have to jump from "Pants user" to "Pants contributor" - there's no "Pants plugin contributor" role in the ecosystem to speak of. I think this is a missed opportunity for Pants--especially in light of the commercial side scaling down--and I think it hurts the longterm ability to build community. Therefore; my thought is that for most new languages, tools, etc, the default aim should be for it to be developed outside of Pants, at its own timescale - with proper support and guidance from the community at large. This will put more pressure on stabilization and definitely add some initial pains, but I think it'd be more sustainable long term. Would love to hear what others think about this, especially if you see yourself in this "inbetween" plugin-but-not-Pants contributor role. * * * I'll let others reiterate their points as they feel necessary! @sureshjoshi @thejcannon pantsbuild/pants