is there any current place where plugins for v2 are being aggregated? Like a set of links to github/gitlab repos or something like that?

that is a fantastic suggestion

i ask because i was about to write my own docker plugin, but i remembered that i had some discussion on here withsomeone about that before

oh yes precisely

Hey Josh, indeed, not yet. But we would love to have something like a Dockerhub or awesome-bazel Were you talking to JP Erkelens?

i was referring to a thread with him, but i haven't really talked because i've only recently gotten back into our pants project since then

Ah, that’s a good idea. Is the idea with it being a wiki that anyone can contribute to it easily? Lower barrier to entry than, say, us maintaining a page on our new docs website?

i think that's the idea

Cool. We still need to do a little more design work around how to support plugin authors to indicate which Pants versions their plugins are compatible with: https://github.com/pantsbuild/pants/issues/10671 In v1, plugins were adopted by Pants into the

pants.contrib

section of our repo, which meant that we maintained them and released them as distinct wheels. A downside of that approach imo was it being too much friction for people to upstream their plugins. And, honestly, it increased our maintenance burden a lot. Now, I think the goal is to be more like Flake8, Pylint, MyPy, etc, where plugins live in dedicated repos. It’s possible/likely that Pants would still want to adopt certain high usage plugins, such as a Docker plugin, but that would likely be in a dedicated repo

i saw the idea of using a

files

target that depends on the outer binary target for docker images, that seems like a pretty sane way to repeatably create a docker build context with Dockerfile, without too much fuss with plugins

i saw the idea of using a files target

It’s pretty easy and cheap to create a new target type now, with the Target API. Much easier than v1 plugins and cleaner code. https://www.pantsbuild.org/docs/target-api-new-targets Actually only three lines of code:

class DockerTarget(Target):
  alias = "docker"
  core_fields = (Dependencies, Sources, MyCustomField)

and then about 3-4 lines of code per custom field that you want to define

that does look simple

But yeah, if the goal is as simple as being able to run

./pants package path/to/foo/Dockerfile

, that’s pretty easy to do. There’s a plugin hook that you use to work with the

binary

goal (soon to be renamed to be

package

). This guide has an example of running

zip

, and instead you’d run

docker

. https://www.pantsbuild.org/docs/plugins-binary-goal We’d be happy to help with it. The implementation isn’t very difficult anymore, unlike v1. The hard part is scoping out the requirements / designing what support means

i see

Awesome. I recommend starting with https://www.pantsbuild.org/docs/rules-api-concepts, which talks about what rules are and everything. The File System, Processes, and Installing Tools pages will be relevant too. For installing tools, you’ll want to use

BinaryPaths

to discover where

docker

is already installed; you certainly won’t want to try to install Docker for the user like we do with other tools. When iterating, you can use a hardcoded path like

/usr/bin/docker

. And then you can move to the guide on using the hook for

binary

. The guide includes an example of us adding Bash language support