#reusing IDs
1 messages ยท Page 1 of 1 (latest)
could have been from running via a local module, too, so maybe using -m with a git ref would work
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.
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
@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)
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
Well, across sessions, they are not 100% reusable. Maybe 80%. Things like secrets might not carry over.
In the same session they should be 100.00% reusable
I did specifically run into secrets not carrying over. That one I can probably work around.
My understanding is that the 80% number will get better over time
(also that number is made up, by me)
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.
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
Correct just waiting for someone to have time to ship it
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.