#reusing IDs

1 messages ยท Page 1 of 1 (latest)

fossil quiver
#

could have been from running via a local module, too, so maybe using -m with a git ref would work

celest sand
#

oh! i figured some stuff, including caching, might be disabled when I ran dagger develop before

#

thanks for the explanation

#

I guess the IDs are part of the previous cell runs that are likely out-of-band of the session. I'll try a few things.

fossil quiver
#

yeah, to be clear you're off the beaten path by doing this, but it should work for most things ๐Ÿ˜› - local blobs are the usual achilles heel

cerulean yacht
#

@celest sand I know you're aware of our plan for embedding an interpreter (possibly bash-compatible) directly in the dagger CLI. One nice side effect of that, is that all calls in a script will be part of the same session. That should improve reusability of IDs across calls.

#

(doesn't help with copy pasting IDs across machines but thought I'd mention it)

celest sand
#

off the beaten path is where I live ๐Ÿ˜„

#

๐Ÿ‘ @cerulean yacht, if they are reusable across calls, do they still have to run within "the same shell script"?

#

i'm asking because unlike Jupyter, Runme does not do block scope sharing

cerulean yacht
celest sand
#

I did specifically run into secrets not carrying over. That one I can probably work around.

cerulean yacht
#

My understanding is that the 80% number will get better over time

#

(also that number is made up, by me)

celest sand
#

Is caching "disabled" for modules in general or only if you're developing? The latter would explain why once I run my dev module it seems like caching is gone.

fossil quiver
#

caching isn't disabled unilaterally, but function calls themselves are currently not cached. it's high on the priority list, i think we're past the bikeshedding part now at least

cerulean yacht
celest sand
#

k, i'll keep my ear to the ground. in any case, I should be able to polish our notebook UX integration irrespective of "ID passing" working in the majority of cases.