Any reason to not have

pex_binaries

->

pex_binary

to mirror

python_sources

->

python_source

?

Sorry if I'm dense, but what would that look like? With entry points etc..

It's theoretically possible! But yeah I don't know how useful it would be. The sole purpose of python_sources is boilerplate reduction - it would be boilerplate hell to require one explicit target per file For pex_binaries, the boilerplate would have to be both offensive enough with individual pex_binary targets, and also DRYable enough that it makes sense to have a target generator

FWIW I'm staring at this build file which is what sparked this:

pex_binary(
    name="deps_commands",
    entry_point="deps_commands.py",
)

pex_binary(
    name="docker_aws_creds",
    entry_point="docker_aws_creds.py",
)

pex_binary(
    name="format_commands",
    entry_point="format_commands.py",
)

pex_binary(
    name="jenkinstrigger",
    entry_point="jenkinstrigger.py",
)

pex_binary(
    name="pip_integration",
    entry_point="pip_integration.py",
)

pex_binary(
    name="presubmit_commands",
    entry_point="presubmit_commands.py",
)

pex_binary(
    name="static_analysis_commands",
    entry_point="static_analysis_commands.py",
)

python_tests(
    name="tests",
)

python_sources()

Perhaps a stop-gap could be a macro 🤔

Oh, right! Yeah I can see how your case is generic enough to DRY up with a pex_binaries target 😆

I think we would want to scope the target generator to something like `pex_binaries_from_sources()`:

pex_binaries_from_sources(
    sources=[
         "static_analysis_commands.py",
         "presubmit_commands.py",
          ...
    ],
)

That is, this is specifically intended for the pattern

pex_binary(name="my_script", entry_point="my_script.py")

. It is not intended for

pex_binary(name="black", script="black", dependencies=["//:black")

(i.e. a console script) That would simplify this a lot, that we don't need to come up with some fancy modeling to gracefully handle both console scripts and

entry_point

where the

entry_point

is a source file

With a macro, can I also plug into

tailor

? (Which is what generated the above file)

You can. You would turn off

[python].tailor_pex_binary_targets

, and then implement your own

tailor

implementation with the Plugin API Although probably better is if we decide to add this to Pants, have

./pants tailor

generate

pex_binaries_from_sources

rather than

pex_binary

. Note that Pants can only generate that type of PEX anyways. A console-script PEX is (usually) file-less, so we have no way of knowing you want us to generate the target

I'll make a feature-request and add it to my own personal backlog

Sweet, thanks Joshua! You can link to https://github.com/pantsbuild/pants/blob/392e613e5f16d56d07a2e8cfe5cecea0cd60d428/build-support/bin/BUILD#L19-L28 in the issue description as a good case study if you'd like Although do note that thanks to putting all the target definitions on a single line, I think this proposal would only end up shaving ~2 lines in that case. That's a little code golfy tho, and it would also reduce the

name=

boilerplate because the target generator would automatically add it for you. I'm thinking this target generator makes sense

Oh wow, congratulations! Aside, without pressure: cute pictures of kiddos are not off-topic here imo 😉 Thank you for your contributions to Pants, on whatever scale is viable.

I'm weird (read: strict) about online pictures of my children 😬 I promise they are cute though!

Haha I will trust your assessment about their cuteness. Totally understandable about looking out for their privacy.