Can someone ELI5

export

vs

export-codegen

?

export

- Export Pants data for use in other tools, such as IDEs.

export-codegen

- Write generated files to

dist/codegen

for use outside of Pants. I'm missing some of the nuances as to what determines whether a new plugin should use one over the other, since they both appear to end up in the

dist

folder. https://www.pantsbuild.org/docs/setting-up-an-ide has some additional examples, which are

virtualenv

vs

protobuf

. The best heuristic I can come up with is that

export

is intended for tooling/support/not-part-of-release, while

export-codegen

would represent files which would be part of the compilation/packaging/binary/production release process. Specifically, I would wonder where the bash completions would go, and based on my assumption above, it's more likely an

export

since it's sourced by the terminal, and has no part in actual production code.

Specifically, I would wonder where the bash completions would go, and based on my assumption above, it’s more likely an

export

since it’s sourced by the terminal, and has no part in actual production code. (

The v1 bash completions were generated by a dedicated

bash-completion

goal.

The ELI5 is "this is probably not super-well designed, sorry"... but in both cases the idea is to take intermediate data that Pants normally produces and uses internally and make it available to the user.

So, my opinions on this (especially with regards to bash completion) are: • I wouldn't want a separate goal for completions. I think there are already too many goals (goal creep), most of which I don't use and don't really even understand, and since goals are generally a critical public API - I think keeping them thin provides a better developer experience, and nesting more advanced usage (like, rolling up all the Pants introspection goals into an

inspect

or something, since they're not directly related to deliverable code) ◦ The whole

fix

vs

fmt

discussion is a good example of how tricky the public API can be, especially if it ever involved a change ◦ Testing bash completions has really pushed this idea with me, seeing which goals don't have options, which do - and just generally trying to tab complete everything to see whether I can guess what can come next • It sounds like

export

and

export-codegen

could feasibly be merged, from a user-centric point-of-view (completely unrelated to technical implementation/details and targets and such) ◦ As a user, knowing that

export

takes "inside Pants" to "outside Pants", that's already good enough to provide me with direction ◦ Having options or targets seem reasonable

./pants export --venv

or

./pants export :protobuf_stuff

or

./pants export --completions

◦ Upon reading that, I'm not a huge fan of how that reads - but at least I could infer what it would do pretty easily upon reading Now, so this doesn't get bogged down as a generic API discussion, specifically with regards to completions - I'm at a bit of an impasse regarding where the completions should go in the next PR. I could put the file somewhere and use...

./pants run

?

You mean to make it accessible to end-users?

Yep, what goal/target/plugin/etc I should use to generate them for user access.

Good question

Yep, my hope was that there was something that could run in the pants script, or part of the pants.toml changed discovery, and auto-export the completions file