https://pantsbuild.org/ logo
Join Slack
Powered by
I might honestly be better off with a pure Bash so...
# development
b
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
h
You can use the JSON module in your Python @rule
As long as you aren't doing side effects, that's legal and idiomatic
b
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
Presently I do that with a wrapper Bash script and a little Python snippet that the wrapper script calls
e
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.
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.
Thats how we do python dep inference.
b
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
e
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.
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.
But, more generally, we're currently missing infra to make one of the bits we wanted to support back in the v1 -> 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.
Then you could write your glue tool here in python or java or whatever languages Pants supports already.
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.
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.
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.
Open in Slack
PreviousNext
Powered by