Provide process isolation for `from_tesseract_api`

[dionhaefner]

Summary

Currently, invoking Tesseracts via from_tesseract_api doesn't really provide any value-add outside of interactive debugging. When workloads can't be containerized (e.g. when interacting with system-level resources or binaries) we're essentially left with a bunch of restrictions and no real advantages over using Python/JAX code directly.

Having from_tesseract_api invoke tesseract-runtime serve in a subprocess would at least make this marginally more useful, because that way we (1) provide process isolation where it matters; (2) allow code with conflicting Python versions / dependencies to inter-operate.

Why is this needed?

One example: pasteurlabs/tesseract-jax#177 – using JAX-within-JAX isn't safe, so T-JAX can trigger deadlocks when using from_tesseract_api.

Usage example

from tesseract_core import Tesseract
tess = Tesseract.from_tesseract_api(".../tesseract_api.py", spawn_dedicated_process=True)

with tess:
    ...

[jpbrodrick89]

I 100% agree that we should offer this as an option, but I'm not entirely sure what the best default is, I'm probably 80-20 leaning towards True too.

[jpbrodrick89]

I'm tempted to actually go with False so it's not a breaking change. wdyt?

[dionhaefner]

Yes for sure, or even introduce a new classmethod.

[apaleyes]

For the sake of argument, to strengthen the motivation here mostly.

I always considered interactive debugging, and thus faster dev cycles, being the only reason from_tesseract_api existed. Consequently, any pipelines built with it can be seen as temporary, running on your own risk, with a clear plan to move on to built tesseracts later. Expanding from_tesseract_api scope can make it less necessary for users to eventually move on from it to proper tesseracts. Is that the effect we want? (i suspect the answer is "even with processes isolation it's still crippled enough")

[dionhaefner]

I don't see much value in constraining what patterns users move on to (or choose to remain at). A Tesseract is anything that quacks like a Tesseract, and I'm fine with whatever implementation users decide is best for them, as long as we're giving them what they need to know to make an informed decision. Agree though that current from_tesseract_api has ~zero legitimate usage outside debugging so it shouldn't be advertised any other way :)