what’s the story on eventually deprecating intrins...
# development
a
what’s the story on eventually deprecating intrinsics? could we make an
externs::mark_deprecated()
?
apropos of nothing in particular!
h
Atm, there’s no need to deprecate. Engine is still private API
a
As in, deciding we no longer want there to exist some mapping from one type to another? I don't think anyone's really thought about it much...
But yeah, calling Python functions from rust is trivial, so, I guess that
a
“engine is still a private api” is great :) that approach has been working great so far
💯 2
h
Agreed! We’re still in too much of an experimental stage to make public. Every iteration, we get closer to a good and stable API
h
what intrinsic does it make sense to deprecate?
a
i said apropos of nothing!!!!
i want to expose a wrapper for
unzip
in v2 because i’m using that for an experiment
i have a branch which makes it SO, SO, SO nice to invoke a bash script as a process execution request
the only blocker is the v2 BinaryTool rules PR
and using bash scripts hygeinically might be a neat way to implement lots of common little fs manipulations
cc @dry-analyst-73584 who asked about using bash scripts in rules a while ago
❤️ 1
h
I'm not sure how I feel about using bash scripts to do file system manipulations
it's easy to get subtle things wrong in bash
like mis-escaping an argument and writing the wrong file or what have you
I'd rather see the engine provide the ability to do whatever file system operations we need
👍 1
a
+1 to specific APIs rather than general bash :)
w
there is an 80/20 line, i expect.