I might honestly be better off with a pure Bash solution and

Question

I might honestly be better off with a pure Bash solution and some way to ensure that `jq` is on the executing machine I m really only using `python` in this case to parse JSON cleanly

hundreds-father-404 · Answer

You can use the JSON module in your Python rule

hundreds-father-404 · Answer

As long as you aren t doing side effects that s legal and idiomatic

bored-art-40741 · Answer

I need to parse a JSON file generated by a binary run within a `Process` then capture certain files named in that JSON file into the output directory for that process This is the Coursier resolve rule where the possibility that the process was run remotely and I depend on the files being fetched on the machine where the process was run means I need to do a fair amount of work within the process itself

bored-art-40741 · Answer

Presently I do that with a wrapper Bash script and a little Python snippet that the wrapper script calls

enough-analyst-54434 · Answer

I wouldn t assume using Pex has overhead or is too big If its not fast the Pants python stack has issues by definitiion We ve spent a ton of time tuning Pants and Pex both here

enough-analyst-54434 · Answer

`await Get PythonExecutable InterpreterConstraints ` should do it That will give you a path you can pass into your Process to do whatever with in a bash script

enough-analyst-54434 · Answer

For example <https github com pantsbuild pants blob 725fd415c29440a6333c0f131f67e0b531fa0497 src python pants backend python dependency inference import parser py L151 L167|https github com pantsbuild pants blob 725fd415c29440a6333c0f131f67e0b531fa0497 thon pants backend python dependency inference import parser py>

enough-analyst-54434 · Answer

Thats how we do python dep inference

bored-art-40741 · Answer

Honestly I m not even sure how the `BashExecutable` strategy is buying me anything if the idea is that I m supposed to be agnostic to remote execution where each `Process` might run on a different executor I might be missing something because I haven t dived deep but I suspect that the JVM rules have just worked incidentally so far because there is no remote execution test or because the remote machine is incidentally similar to the local machine

enough-analyst-54434 · Answer

BashBinary is that what you mean by BashExecutable just future proofs you to a location independent way to get bash say the core offers up precompiled statically linked bash in the future It s true that your own ` usr bin env bash` script today is just as good

enough-analyst-54434 · Answer

PythonExecutable basically the same Except if your script needs a particular Python which it doesn t or you can make it so it doesn t

enough-analyst-54434 · Answer

But more generally we re currently missing infra to make one of the bits we wanted to support back in the v1 gt v2 talks building local binaries for use in rules Ideally you could `digest = await Get Digest Address my custom binary target ` and get a tool you wrote in repo bootstrapped and useable by your rule

enough-analyst-54434 · Answer

Then you could write your glue tool here in python or java or whatever languages Pants supports already

enough-analyst-54434 · Answer

You should be able to do that today with more boilerplate but we offer no way to then package that binary in the Pants dists when we release Pants So it really only works for loose source local plugins today that you don t plan to distribute

enough-analyst-54434 · Answer

This goes back to supporting 1st class for example the 4sq some codegen thrifty plugin thing you guys managed to barely get working in the v1 scheme

enough-analyst-54434 · Answer

Or the Pants v1 junit runner That was in repo but needed to be built and pushed to maven central out of band to then be used in Pants v1