I'm iterating on the quickstart Starlark script. This involves a lot of "make a change, then kurtosis run, repeat". Pains:
My enclave name changes every time
I have to wait the 3s for a new enclave to boot up every time I want to rerun
Sometimes I make an immediate, dumb error (e.g. Starlark typo). So I make a half-second change, then need to wait another
Current behavior
Make change to Starlark script
Try a kurtosis run, which involves a ~3s enclave startup time before the SL even runs
Fix errors or add more code
Repeat
Desired behavior
I can tell Kurtosis to start watching a SL script or package. Any time I write a change, Kurtosis will empty out the enclave and redo everything as if I ran kurtosis run ....... I'll also need to be able to define parameters for this live-reloading, if my SL script or package is parameterized.
This will be extra useful when we have static port bindings, so that a user can set up static port bindings for an enclave + servicename + port ID, and the enclave ID won't keep changing under them.
How important is this feature or improvement to you?
Painful, the lack of this feature makes using Kurtosis frictionful.
Background and motivation
I'm iterating on the quickstart Starlark script. This involves a lot of "make a change, then
kurtosis run
, repeat". Pains:Current behavior
kurtosis run
, which involves a ~3s enclave startup time before the SL even runsDesired behavior
I can tell Kurtosis to start watching a SL script or package. Any time I write a change, Kurtosis will empty out the enclave and redo everything as if I ran
kurtosis run ......
. I'll also need to be able to define parameters for this live-reloading, if my SL script or package is parameterized.This will be extra useful when we have static port bindings, so that a user can set up static port bindings for an enclave + servicename + port ID, and the enclave ID won't keep changing under them.
How important is this feature or improvement to you?
Painful, the lack of this feature makes using Kurtosis frictionful.