https://pantsbuild.org/ logo
#general
Title
# general
n

nice-florist-55958

07/25/2022, 5:24 PM
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.
b

bitter-ability-32190

07/25/2022, 5:27 PM
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
👍 1
e

enough-analyst-54434

07/25/2022, 5:54 PM
...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.
So, beyond Josh's point about internals, targets, etc. The underlying technology of actually producing a - say - Ruby executable zip archive - would need to be sussed.
As far as I'm aware, Ruby does not has a zipimporter equivalent; so, the zip shebang would need to be /bin/sh and the header a POSIX-compliant sh script that searched for unzip and went from there.
b

bitter-ability-32190

07/25/2022, 6:00 PM
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)
e

enough-analyst-54434

07/25/2022, 6:00 PM
How does pyoxidizer produce a ruby single file executable?
b

bitter-ability-32190

07/25/2022, 6:01 PM
It doesn't. It produces a Python one
e

enough-analyst-54434

07/25/2022, 6:01 PM
But Taylor's question is about everything except Python IIUC
b

bitter-ability-32190

07/25/2022, 6:02 PM
Ahhhh I see now. I misunderstood on first read 😅
w

witty-crayon-22786

07/26/2022, 4:00 PM
@nice-florist-55958: are you familiar with https://www.pantsbuild.org/docs/run-shell-commands ?
6 Views