I've found a missing piece in the adhoc_tool toolb...
# development
g
I've found a missing piece in the adhoc_tool toolbox -- one cannot download a
file
using
http_source
and use it as the runnable. So... Should that be another target, or should
file
be runnable (via a bool?)? Thoughts?
b
I think... Ugh the mental model of some of these things is so fluid. Ok either http_source marks everything executable (because why not?) Or gains a new field (if that's feasible)
g
I guess it should be on
file
directly, so something like
Copy code
file(
    name=...,
    source=str | http_source | per_platform...,
    executable=bool,
)
I've seen some dynamic filtering with I think fieldsets that seems like a good use-case for this.
b
I don't think that's a good idea. The most common case for
file
is the file on disk, and the digest should simply respect that file's perms
g
Oh, the issue isn't the perms (but we should fix them for downloaded files). The problem is that the file target itself can't be ran.
The way adhoc tool works it currently explodes here: https://github.com/pantsbuild/pants/blob/a4fbfb8db2dfcb7d2872ba981285db0e81c48b2f/src/python/pants/core/util_rules/adhoc_process_support.py#L404-L421, violently, if you pass something non-runnable as the runnable target.
b
😔
g
The other alternative would be that if the thing isn't runnable by pants we shim it with a script at that point and try to run it that way, but it seems like an extra step
b
So maybe we mark all files as runnable?
And then if it turns out not to be executable, that's a pretty vanilla and expected error?
Resources too 🙄
g
everything is runnable if we allow it to fail 😉
b
IMO I was the one that didn't want to assume that everything was runnable hermetically, and suggested the enum. But the reality is we only ever can assume everything is hermetically runnable, because we simply don't know at the plugin level.
So with hindsight we might as well remove the enum and lean into it 🤔
g
Hmm. I think the enum is fine, though it'd make it possible to fake this with
run_shell_command
if we didn't have it (assuming you talk about the RunInSandboxBehavior). But it seems tangential to the issue?
b
Possibly, I'm only grokking the surface of this issue since I don't have the code in front of me
g