It would be really nice to write code that's pants...
# development
h
It would be really nice to write code that's pants-agnostic, but whose datatypes can be used as Pants products. So rules can be relatively thin wrappers around functionality that knows nothing of pants.
👌 2
a
yes!!!!
w
that's fairly unlikely due to the need for sandboxing
a
stu and i so far disagree on this point
w
we're not enforcing it as well as we need to be in the long term
examples: 1) no network access, 2) no filesystem access, 3) etc
4) no sideeffects
a
i see that as something we can arrive at, along with developing python tools as benjy depicts that can work in that environment instead of accessing the filesystem directly
w
well, sure. but that means the opposite of "knows nothing of pants"
h
Well, rules today can call arbitrary code that can side-effect etc.
We're relying on discipline, no?
w
right: as i said, we're definitely not doing well at this yet
a
i view "tools that can be used in a sandboxed model" as a strict superset of tools that can't
w
subset?
a
superset!
h
but any enforcement would presumably have to introspect the rule and all its dependencies?
So those dependencies don't have to "know about pants", although they do need to not have side effects...
?
a
while i usually just think of "enforcement" as "hopefully we can make everything that doesn't assume a sandboxed environment break early and loudly"
w
@happy-kitchen-89482: no. generally sandboxes use hooks or full replacements of API calls to make them fail
and the effect of that is "the thing fails", and you need to change your usage
h
But presumably those are monkeypatched
The calling code thinks its calling the normal stdlib functions?
So it needs to know that there are stdlib functions it must not call, sure, but it doesn't need to depend on Pants, is more my point.
If I'm understanding this sandbox implementation correctly.
w
Right. So it must not do filesystem access via read/open. But then it needs to know how to do it correctly
(or just be less useful)
a
it's very possible to pass e.g. file handles through the engine and i am using that right now to implement a v2 ruleset which communicates via BSP to a subprocess. that wouldn't lead to a remotable process execution, but it does work with e.g.
json.dump()
and other python libs
w
@aloof-angle-91616: er, but that is not code that we would ship. it totally violates the sandbox
like, we'd have to make it part of the API
a
so yes
w
if we actually build it in as an intrinsic, so it's a supported API of the sandbox, then fine. but that's definitely not "unmodified python code"
a
that is exactly what i am thinking
the process currently runs one-shot to completion within a v1 pants task
i want to figure out restarting a v2 rule (e.g. one that processes messages from a subprocess) in order to introduce this as an actually performant solution
but have been avoiding that for now
h
I guess the specific example I have in mind doesn't require filesystem access or process execution, so that's coloring my thinking...
w
yea
a
it's actually pretty easy to write python that doesn't do this, imho. not sure if anyone agrees with me yet
w
the example you used talked about passing in a socket =/
i'm sure there are cases, i just don't know how widespread they are, and my assumption is: not very
a
yes, and i think passing in a socket can be made cacheable
w
yes. but it would be exceedingly unlikely to be unmodified python
a
working on it!!