conceptually I would just like to say "please run this command based on these files, some build results will end up here"

But yeah, we already have a "normal" build system and Pants being Python is very tempting, but I would ideally just like to wrap the existing system in Pants (then split it up later) but not seeing an easy way to do this

Like we have 5 or 6 build steps already, I think we could use Pants and caching to get advantages from the "same input/same output" principle.

Well there's Django stuff like

manage.py compilemessages

(for translation files), I could write up wrapper files for this probably?

Regarding Python, there is already support for what you’re describing. Pants will understand when the inputs to the test command haven’t changed and will leverage the cache for those tests. Another option is

./pants --changed-since=HEAD test

, which will find all the changed files sine that commit and only run those

can I make a`files` declaration for stuff that is generated from some other command (like a plugin that would run the commands above)?

sorry for spamming on this, it's very nice to be able to get help on this kind of stuff though

no, we don’t commit it

Okay, then codegen would likely be more idiomatic, but in the meantime, I think we could still make it work. The semi-unidiomatic thing is that you will want to check in your BUILD file to VCS, so you will want your BUILD file defined one level above

dist

, like at the root level. Then, you could use a

sources

glob, like this:

files(
  name="static_assets",
  sources=["dist/main.js", "dist/assets/*.png"],
)

Your targets can then depend on

//:static_assets

, where the

//

clarifies this target is at the build root.

What I'll do here is make a new repo with a simple version of my use case and I'll share the link in this Slack, and try to figure out the details

src/python/pants/core/project_info/cloc.py

is a good example of a stand-alone goal that does something similar to what you’ll want for the Grunt goal. Ignore lines 26-46. First step to your new goal: create a subclass of

GoalSubsystem

and

Goal

, very similar to this file.

GoalSubsystem

is the public api, like any options and the name of the goal. Then, the

@goal_rule

is where the interesting logic happens. High level flow of what’s going on: 1) We’re asking for a couple things to be given to us by the V2 engine. These will be given via dependency injection; we don’t care how Pants gets us these things. 2) One of the things we’re asking for in the function signature is

SourcesSnapshots

. This is a way to ask for source files, where we don’t care at all about the metadata in targets. All we care about is the raw source files. If a user runs

./pants cloc :example

, we get all the source files belonging to the target

example

. If they say

./pants cloc example.js

, we’ll get that JS file. 3) We set up a

Process

, which is very similar to Python’s

subprocess.Popen

but is a way the Pants engine understands it and does things like safe caching. Note that we run

/usr/bin/perl

. For an initial prototype, it will be easiest if you can use an absolute path like

/usr/bin/grunt

. We can help you to generify this once it works. Also, note the

input_files

to populate the chroot with the files we need, and

output_files

to “capture” the result. 4)

await Get[ProcessResult](Process, req)

actually runs the process -- The other relevant file is

src/python/pants/core/goals/binary.py

, lines 69-71. It shows how to materialize files from a tmpdir into the actual build root so that you write to

dist/