Could

pex_binary

be generalized to

script_binary

for dynamic scripting languages Pants doesn't support yet? I'm imagining a target with similar semantics but with just a script file entry point to be executed by the OS (and so with whatever is in the file's shebang line, i.e., the language's interpreter). Dependencies would just be other first-party source-like targets such as

resources, python_sources, shell_sources, etc.

bundled as a collection of files relative to the entry script (or relocatable to it). A new target

script_sources

instead of

resources

as a generic stand-in could be added too. This would allow other projects based

q/kdb

,

bash

,

nodejs

, or any other interpreted language to formally use Pants, both to enumerate their sources and to package themselves into a single executable file. Migration would also be easier once any given language has first-class support. At present, could the existing

archive

(for the executable) and

resources

(for the sources) targets be post-processed after the Pants packaging step to be executable using a given interpreter path? At the moment, all I can think of is to lightly use Python as a glue language and package a

pex_binary

with an entry point script that just sub-processes out to the actual script that the author wants executed.

It could, but the way the Pants internals are structured makes it challenging. I have an upcoming proposal that tries shift the paradigm in a direction that would allow this, but for now I think you'll have to do it in a plugin. The plugin would expose a new target whose guts declare a codegenerator from PEX binary to

file

or `resource`: https://www.pantsbuild.org/docs/plugins-codegen

...and to package themselves into a single executable file.

That part is not free. This only works with Python because Python has a built-in zipimporter. For generic support, the zip header script would need to be something like Pex's

--sh-boot

script but that knew how to unpack before handing off to the language runtime you would be targeting.

There's also https://www.pantsbuild.org/docs/reference-pyoxidizer_binary to consider. It'll hit the same internals issue though (but possibly works around the PEX limitations)

How does pyoxidizer produce a ruby single file executable?

It doesn't. It produces a Python one

But Taylor's question is about everything except Python IIUC

Ahhhh I see now. I misunderstood on first read 😅

@nice-florist-55958: are you familiar with https://www.pantsbuild.org/docs/run-shell-commands ?